Access tokens are credential strings representing authorization to access a protected resource. Client applications obtain access tokens by making OAuth 2 or OpenID Connect requests to an authorization server, and resource servers require clients to authenticate using them.
Access tokens are obtained from the token endpoint (when using the authorization code, password, client credentials, or refresh token grant type) or from the authorization endpoint (when using the implicit grant type). Access tokens are typically granted on behalf of a specific authenticated user; those that are granted directly to applications are called application tokens.
Clients present access tokens when making requests to a resource server (for example, the Data Governance Broker’s UserInfo endpoint or SCIM endpoints) using bearer token authentication as described by RFC 7650.
An example request using bearer token authentication:
GET /userinfo HTTP/1.1 Accept: application/json Accept-Encoding: gzip, deflate Authorization: Bearer eyJraWQi... Connection: keep-alive Content-Type: application/json; charset=utf-8 Host: example.com:443
The access tokens issued by the Data Governance Broker are signed JWTs containing the following claims, which are based on claims defined in RFC 7662:
|jti||string||A non-private unique identifier for the token.|
|sub||string||The unique identifier for the subject of the token; that is, the authenticated user represented by the token. This is a relative URL of the form
|iss||string||The issuer of the token. This should be a URL of the form
|iat||number||The date and time when the token was issued. This is an integer timestamp, measured in the number of seconds since January 1, 1970 UTC.|
|exp||number||The date and time when the token will expire. This is an integer timestamp, measured in the number of seconds since January 1, 1970 UTC. The access token must not be accepted if the
|scope||string||The set of scopes associated with the token. This is a string containing a space-delimited list of scope names.|
|client_id||string||The client ID of the client that requested the token.|
Access tokens granted using the client credentials grant type are called application tokens. Application tokens represent access to either:
- Resources owned by the client rather than any specific end user, or
- Resources belonging to multiple end users. For example, an application token is often needed to perform a SCIM search.
Application tokens potentially offer broad access with fewer constraints than typical access tokens, and administrators should take care to limit access to application tokens to highly trusted clients. Importantly, application tokens are granted directly to clients without the involvement of an end user. Consent cannot therefore be obtained from end users before granting an application token.
Application tokens differ from access tokens granted for end users in other crucial ways:
- They are not persisted to the user store.
- They cannot be revoked.
- They lack the
Because they cannot be revoked, application tokens are typically configured to expire after a short interval.