Revokes an access token previously obtained. This method results in the revocation of an access token by a party such that it cannot be used by the requesting party to gain access to a service.

Parties MUST support a POST call to a /token/revoke endpoint to revoke an access token

Request

Headers

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

Header		Description
`Content-Type`	Required	as the OAuth 2.0 Token Revocation specified in RFC7009. 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/revoke 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/revoke endpoint

Parameters		Description
`grant_type`	Required	as the OAuth 2.0 grant type. MUST be equal to `client_credentials`.
`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 DSGO Authentication JWT. Used in DSGO for authentication of the client identification.
`token`	Required	as the OAuth 2.0 access token. MUST be equal to access token that the client wants revoked as specified in RFC7009

Example request body for a POST /token/revoke call

{ 
    "grant_type"="client_credentials"
    "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...]"&
    "token"="aW2ys9NGE8RjHPZ4mytQivkWJO5HGQCYJ7VyMNGGDLIOw"
}

Response

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

200 OK

When the access token is successfully revoked, or an invalid token is submitted, the data service provider should send an OK result.

Parties MUST respond with a 200 OK to a successful POST call to a /token/revoke endpoint

Parties MUST respond with a 200 OK to a POST call to a /token/revoke endpoint containing an invalid access token

Parties MUST no longer accept the revoked the access token after a 200 OK response is responded

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/revoke 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
`unsupported_token_type`	Optional	MUST be as specified in RFC 7009 section 2.2.1 if the server does not support the revocation of the presented token type.

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

{
    "error":"invalid_request"
}

503 Service Unavailable

When a 503 response code is sent the requesting party must assume that the token still exists and may retry after a reasonable delay.

Parties MAY include a Retry-After header in the 503 response to a /token/revoke endpoint to indicate the expected unavailability of the service