Creates and provides a new access token. This method results in an access token with which the requesting party can gain access to a service at the providing party. The format of an access token is not defined by this specification. They are left to the server and should be opaque to a requesting party.

Parties MUST support a POST call to a /token endpoint to create a new access token

Prerequisites

In OAuth 2.0 clients are typically “pre-registered” by the server. In the DSGO this is not desirable as data can be shared with previously unknown clients. Therefore client identification and authentication is performed via a check by the DSGO Trust Framework Authority via the Trust Framework catalog. For more details see the Access Token flow.

Parties MUST NOT pre-register clients

Request

Headers

Parties MUST validate that a POST request to a /token endpoint contains the HTTP headers as described in the table below

Header		Description
`Content-Type`	Required	as the OAuth 2.0 JWT bearer profile, specified in RFC7523. Defines request body content type. MUST be equal to `application/x-www-form-urlencoded`

Parameters

For information about the parameters that are common to trust framework’s API’s see Generic API Requirements.

Parties MUST validate that a POST request to a /token endpoint contains the parameters as described in the table below

Parties MUST validate the client credentials in the client_assertion received in a POST to a /token endpoint, by comparing the client_id to the iss and sub claim in the client_assertion and the subject_name of the QSEAL used to sign the client_assertion

Parameters		Description
`grant_type`	Required	as the OAuth 2.0 grant type. MUST be equal to `client_credentials`.
`scope`	Required	as the OAuth 2.0 scope. MUST contain the value `dsgo ishare` to indicate usage within the DSGO, in alignment with iSHARE (v2.0).
`client_id`	Required	as the OAuth 2.0 JWT bearer profile, specified in RFC7523. MUST contain a valid Organisation ID of the data service consumer, containing an EORI or KvK number. Used in DSGO for client identification.
`client_assertion_type`	Required	as the OAuth 2.0 JWT bearer profile, specified in RFC7523. MUST be equal to `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`.
`client_assertion`	Required	as the OAuth 2.0 JWT bearer profile, specified in RFC7523. MUST contain a signed JWT (Authentication JWT or Onweergbaarheid JWT). Used in DSGO for authentication of the client.

Example request body for a POST /token call

{ 
    "grant_type"="client_credentials"&
    "scope"="dsgo ishare"& 
    "client_id"="EU.EORI.NL000000001"& 
    "client_assertion_type"="urn:ietf:params:oauth:client-assertion-type:jwt-bearer"&
    "client_assertion"="eyJhbGciOiJSUzI1NiIsImtpZCI6IjIyIn0.eyJpc3Mi[...omitted for brevity...].cC4hiUPo[...omitted for brevity...]"
}

Response

For information about the parameters that are common to trust framework’s API’s see Generic API Requirements.

200 OK

When a valid request is sent an OK result should be returned and an access token is sent.

Headers

Parties MUST include the HTTP headers as described in the table below in a response to a POST request to a /token endpoint

Header		Description
`Content-Type`	Required	Defines response body content type. MUST be equal to `application/json`.

Parameters

Parties MUST include an access token as described in the table below in the HTTP payload in a response to a successful POST request to a /token endpoint

Parties MUST NOT issue refresh tokens

Parameters		Description
`access_token`	Required	as the OAuth 2.0 access token, specified in RFC6749. This MUST contain an access token which will be used to access endpoints that require authorization.
`token_type`	Required	as the OAuth 2.0 JWT bearer profile, specified in RFC7523. MUST be equal to `bearer`.
`expires_in`	Required	Access token expiration time in seconds. SHOULD be `3600`.

An example M2M Authorization response (200 OK) is presented below

Example HTTP payload in a response to a success POST to the /token endpoint

{
    "access_token":"aW2ys9NGE8RjHPZ4mytQivkWJO5HGQCYJ7VyMNGGDLIOw",
    "token_type":"bearer",
    "expires_in":3600
}

400 Bad Request

When invalid request is sent a bad request result should be returned.

Parties MUST include the parameters as described in the table below in the HTTP payload in a response to a failed POST request to a /token endpoint

Parameters		Description
`error`	Required	as specified in OAuth 2.0 section 5.2, MUST be an error code.
`error_description`	Optional	as specified in OAuth 2.0 section 5.2, MUST be a human-readable text providing additional information.
`error_uri`	Optional	as specified in OAuth 2.0 section 5.2, MUST be an URI identifying a human-readable web page with information about the error.

Example HTTP payload in a response to a failed POST to the /token endpoint

{
    "error":"invalid_request"
}