# Revoke a token

# Description

Revokes an access token so that it becomes invalid before it expires (see RFC 7009)

# Request

To revoke an access token, the client application must send the following request to TRIDENT using TLS

`POST /trustedx-authserver/oauth/token/revoke`

## Content-Type Header

`Content-Type: application/x-www-form-urlencoded; charset=UTF-8`

## Body

Parameter | Usage | Description
`token` | Required | Token to be revoked
`token_type_hint` | Optional | Type of token to be revoked. TRIDENT currently does not take into account this parameter. We recommend not using it or assigning it the value `"access_token"`.

## Authentication of the Client Application

Public client applications (installed/native applications) do not need to authenticate to use this operation.

In other cases, the application must authenticate using the HTTP basic authentication scheme. As credentials, the application must specify the identifier and secret assigned to the application during its registration in TRIDENT (the Client identifier and Client secret fields of the Client application), encoded as specified by OAuth 2.0.

Specifically, the application must include an `Authorization` header with the following structure:

`Authorization: Basic {credentials}`

Where `{credentials}` is the result of encoding the client identifier of the application `(client_id`) and its secret (`client_secret`) as follows:

`base64(url_encode(utf8(client_id)) ':' url_encode(utf8(client_secret)))`

The meaning of the above pseudocode is:

- Encode `client_id` first in UTF-8 and then according to the URL character escape rules.

- Encode `client_secret` first in UTF-8 and then according to the URL character escape rules.

- Concatenate both using colons (“:”) as the separator.

- Encode the resulting string in base64 without line breaks.

The rules for escaping characters in URLs are those defined for the application/x-www-form-urlencoded MIME format in the HTML specification that must be applied to the bytes resulting from encoding the identifier or secret in UTF-8. See the example below

Note

The HTTP basic authentication scheme defined in RFC 2617 does not specify that the credentials must be encoded in UTF-8 and in URL format. The use of these additional encoding rules is part of OAuth 2.0. If a software library or tool that generates the `Authorization` header as per RFC 2617 is used, keep this in mind, especially when the identifier or secret contains extended symbols or characters.

## Example

This example shows a request for revoking a token sent by an application with the `"demapp"` identifier and the `"om+4a_.CE-qüKC mK:3&V"` secret. Ellipses and line breaks have been included to facilitate reading.

`POST /trustedx-authserver/oauth/token/revoke HTTP/1.1`
`Host: trustedx.demo.com:443`
`Authorization: Basic ZGVtb2FwcDpvbSUyQjRhXy5DRS1xJUMzJUJDS0MrbUslM0EzJTI2Vg==`
`Content-Type: application/x-www-form-urlencoded; charset=UTF-8`
`token=a5f8...6aaf`

Before they were included in the `Authorization` header, the client identifier and secret were encoded in UTF-8 in URL format. Specifically, the value of the header was generated as `base64("demoapp:om%2B4a_.CE-q%C3%BCKC+mK%3A3%26V")` after the following conversions were applied:

- The `"+"` character was converted to `"%2B"`.

- The `"ü"` character, which is encoded in UTF-8 with two bytes, was converted to `"%C3%BC"`.

- The `" "` (space) was converted to `"+"` (TRIDENT also accepts encoding it as `"%20"`).

- The `":"` character was converted to `"%3A"`.

- The `"&"` character was converted to `"%26"`.

The rest of the characters of the identifier and the secret used in this example do not need conversions.

# Response

## Status-Line

Both if the access token is revoked successfully and if it is not revoked because it is invalid (e.g., because it expired, was already revoked, or was never generated), the HTTP response will contain the following Status-Line (see HTTP Response Status for all the possible cases):

`HTTP/1.1 200 OK`