APIv4 (Draft)#

NOTE: Work in Progress!

This document describes version 4 of the API provided by eduVPN and Let’s Connect! servers.

See Changes from APIv3 for a list of changes since our current APIv3.

The API is intended to be used by the eduVPN and Let’s Connect! applications. If you are creating your own application, look here how to register your own client in the server.

Using this document you should be able to implement the API in your VPN client, or provide the same API for your VPN server to leverage the existing VPN clients.

Standards#

We use a simple HTTP API protected by OAuth 2, following all recommendations of the OAuth 2.1 draft specification.

For some further implementation notes and recommendations for the client, please read this document.

Server Discovery#

As there are many servers running eduVPN / Let’s Connect! you need to know which server you need to connect to. This can be either hard-coded in the application, the user can be asked to provide a server address or a “discovery” can be implemented.

For eduVPN specific we implement “server discovery” as documented here.

Server Endpoint Discovery#

A “well-known” URL is provided to figure out the OAuth and API endpoint one has to use. The document can be retrieved from /.well-known/vpn-user-portal, e.g.:

{
    "api": {
        "http://eduvpn.org/api#4": {
            "api_endpoint": "https://vpn.example.org/vpn-user-portal/api/v4",
            "authorization_endpoint": "https://vpn.example.org/vpn-user-portal/oauth/authorize",
            "token_endpoint": "https://vpn.example.org/vpn-user-portal/oauth/token"
        }
    },
    "v": "4.0.0-1.fc41"
}

Servers that provide the http://eduvpn.org/api#4 key under api, support this API.

The application MUST retrieve this document at least once per application run, i.e. if the user restarts the application this document MUST be retrieved fresh for each server the client interacts with. An application MAY opt to refresh the document more frequently.

Endpoint Location#

When fetching this document, redirects, e.g. 301, 302, 303, MUST be followed, but MUST NOT allow redirect to anything else than other https:// URLs, e.g. redirects to http:// MUST be rejected.

Authorization Endpoint#

The authorization_endpoint is used to obtain an authorization code through an “Authorization Request”. The following parameters MUST be set:

client_id;
redirect_uri;
response_type: MUST be code;
scope: MUST be config;
state;
code_challenge_method: MUST be S256;
code_challenge.

The authorization_endpoint with its parameters set MUST be opened in the platform’s default browser or follow the platform’s best practice dealing with application authorization(s). The redirect_uri parameter MUST point back to a location the application can intercept.

All error conditions, both during the authorization phase AND when talking to the API endpoint MUST be handled according to the OAuth specification(s).

Token Endpoint#

The token_endpoint is used to exchange the authorization code, as obtained through the redirect_uri as part of the authorization, for an access and refresh token. It is also used to retrieve new access tokens when the current access token expires.

All error conditions, both during the authorization phase AND when talking to the API endpoint MUST be handled according to the OAuth specification(s).

Using the API#

Every API call below will include a cURL example, and an example response that can be expected.

All POST requests MUST be sent encoded as application/x-www-form-urlencoded.

The API can be used with the access token obtained using the OAuth flow as documented above. The following API calls are available:

Get “Info” from the VPN server, including a list of available profiles (/info);
“Connect” to a VPN profile (/connect);
“Disconnect” from a VPN profile (/disconnect)

API Calls#

Info#

This call will show the available VPN profiles for this instance. This will allow the application to show the user which profiles are available.

This GET call has no parameters.

Request#

Request all available VPN profiles:

$ curl \
    -H "Authorization: Bearer abcdefgh" \
    https://vpn.example.org/vpn-user-portal/api/v4/info

Response#

HTTP/1.1 200 OK
Content-Type: application/json

{
    "info": {
        "profile_list": [
            {
                "profile_description": {
                    "en": "Access to files and printers.",
                    "nl": "Toegang tot bestanden en printers."
                },
                "profile_id": "employees",
                "profile_name": {
                    "en": "Employees",
                    "nl": "Medewerkers"
                },
                "profile_priority": 0
            },
            {
                "profile_description": {
                    "en": "Access to network and virtual machine management systems."
                },
                "profile_id": "admins",
                "profile_name": {
                    "en": "Administrators"
                },
                "profile_priority": 5
            }
        ]
    }
}

The fields are described in the table below, look under the table for additional information.

Key	Always Set	Type	Description	Since	Deprecated
`profile_priority`	Yes	`int`	Hint for client to sorting the available profiles, highest number first	4.0.0	No
`profile_id`	Yes	`string`	Profile ID	4.0.0	No
`profile_name`	Yes	`object`	Human readable name(s) for profile	4.0.0	No
`profile_description`	No	`object`	Human readable description(s) for profile	4.0.0	No

The profile_name is a JSON object of the type map[string]string, i.e. it contains a mapping from language code to (translated) string. It should contain a short (human readable) name of the profile, e.g. “Students”.

The profile_description is a JSON object of the type map[string]string, i.e. it contains a mapping from language code to (translated) string. It should contain a longer (human readable) description of the profile, e.g. “Get access to the library, file shares and printers.”

The profile_priority field is documented here.

Connect#

Get the profile configuration for the profile you want to connect to.

Request#

Connect to the “Employees” profile (employees) and specify a WireGuard public key for when WireGuard will be used:

$ curl \
    -d "profile_id=employees" \
    --data-urlencode "public_key=nmZ5ExqRpLgJV9yWKlaC7KQ7EAN7eRJ4XBz9eHJPmUU=" \
    -H "Authorization: Bearer abcdefgh" \
    -H "Accept: application/x-wireguard-profile" \
    "https://vpn.example.org/vpn-user-portal/api/v4/connect"

NOTE: a call to /connect immediately invalidates any previously obtained VPN configuration that belongs to the same OAuth authorization.

The POST request has the following parameters:

Parameter	Required	Value(s)
`profile_id`	Yes	The `profile_id`, as obtained from the `/info` response
`public_key`	Yes	A WireGuard public key when `Accept` header is, or contains `application/x-wireguard-profile`

The HTTP Accept request header can be used to persuade the VPN server to only return VPN configurations of a particular protocol.

See VPN Protocol Selection for more info on how it is determined which VPN configuration file is returned.

Profile ID#

The value of profile_id MUST be of one of the identifiers for the profiles returned in the /info response.

Public Key#

The public_key parameter MUST be set. The value of public_key MUST be a valid WireGuard public key. It has this format:

$ wg genkey | wg pubkey
e4C2dNBB7k/U8KjS+xZdbicbZsqR1BqWIr1l924P3R4=

TODO: do we actually want/need this?! For every call to /connect you MUST (SHOULD?) use the public key of a freshly generated keypair. You MUST NOT reuse the same keypair.

Response#

You’ll get a WireGuard client configuration in the wg(8) format with Content-Type: application/x-wireguard-profile, e.g.:

Expires: Fri, 06 Aug 2021 03:59:59 GMT
Content-Type: application/x-wireguard-profile

[Interface]
Address = 10.43.43.2/24,fd43::2/64
DNS = 9.9.9.9,2620:fe::fe

[Peer]
PublicKey = iWAHXts9w9fQVEbA5pVriPlAYMwwEPD5XcVCZDZn1AE=
AllowedIPs = 0.0.0.0/0,::/0
Endpoint = vpn.example:51820

As can be seen in the examples, this API response also contains an Expires header that indicates when the VPN configuration will expire.

The API client MUST add the PrivateKey field under [Interface] with the private key that belongs to the public key specified in the /connect request in order to get a full wg(8) compatible configuration file.

For WireGuard over TCP, see WireGuard over TCP.

Disconnect#

This call is to indicate to the server that the VPN session(s) belonging to this OAuth authorization can be terminated.

The purpose of this call is to clean up on the server, e.g. release the IP address reserved for the client.

Request#

$ curl -X POST \
    -H "Authorization: Bearer abcdefgh" \
    "https://vpn.example.org/vpn-user-portal/api/v4/disconnect"

This POST call has no parameters.

Response#

HTTP/1.1 204 No Content

Error Responses#

Call	Example Message	Code	Description
`/connect`	`no such "profile_id"`	400 (`Bad Request`)	When the profile does not exist, or the user has no permission
`/connect`	`invalid value for "profile_id"`	400 (`Bad Request`)	When the syntax for the `profile_id` is invalid
`/connect`	`?`	406 (`Not Acceptable`)	When the profile does not support the VPN protocol(s) supported by the client (or vice versa)

TODO: other errors could be invalid public key, invalid Accept header, missing parameters, etc.

An example:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{"error":"no such \"profile_id\""}

In addition to these errors, there can also be an error with the server that we did not anticipate or is an unusual situation. In that case the response code will be 500 and the JSON error key will contain more information about the error.

VPN Protocol Selection#

The client can influence the VPN transport decision by using the HTTP request Accept header.

Value	Description
`application/x-wireguard-profile`	Accept WireGuard configurations
`application/x-openvpn-profile`	Accept OpenVPN configurations

A VPN client that supports both would have this HTTP Accept request header value:

Accept: application/x-wireguard-profile,application/x-openvpn-profile

The Accept request header MUST be set for all calls to /connect.

WireGuard over TCP#

For tunneling WireGuard over TCP, we use ProxyGuard. For the use of ProxyGuard, we need to know a URL to use with ProxyGuard. By convention, we use the value of the Endpoint configuration key to construct it from that.

The value of Endpoint is of the format HOST:PORT. The URL for ProxyGuard becomes https://HOST/proxyguard/HOST. As the Endpoint field also supports IPv4 and IPv6 addresses, we support those as well.

Endpoint	ProxyGuard URL
`vpn.example:51820`	`https://vpn.example/proxyguard/vpn.example`
`192.0.2.5:443`	`https://192.0.2.5/proxyguard/192.0.2.5`
`[2001:db8::5]:51820`	`https://[2001:db8::5]/proxyguard/[2001:db8::5]`

NOTE: it is possible to get a server certificate for a literal IP address, Let’s Encrypt will support that in the near future.

TBD: do we still want to support the option to only have one designated reverse proxy in case of multi-node deployments, like we currently do in 3.x?

TBD: the second occurrence of /HOST can be removed from the URL if we are sure we don’t want to support a single proxy (see previous point)

TBD: do we also want to use the square brackets in the path of the URL if it is an IPv6 address?

Changes from APIv3#

The API was updated to drop a bunch of things no longer needed and simplify the calls. We currently do not describe OpenVPN, but this MAY need to be supported in order to have older servers that still use OpenVPN support APIv4 as well.

X-Proxy-Endpoint header is used to indicated WireGuard+TCP support
/info call display_name has been renamed to profile_name and is always an object now
/info call profile_description has been added and can be used to give extra information about a profile, is always an object
/info call no longer returns default_gateway (was only needed for OpenVPN+Linux)
/info call no longer returns vpn_proto_list (was only needed for OpenVPN+Linux)
/info call no longer returns dns_search_domain_list (was only needed for OpenVPN+Linux)
/info call vpn_proto_transport_list removed
/connect call now requires public_key
/connect call no longer supports prefer_tcp
/connect call now MUST be sent with Accept header indicating the supported VPN protocol
/connect responds with 400 code when profile does not exist