OAuth2 Tokens

In OAuth2, security tokens transport authorization information between clients, user-agents, authentication servers, and resource servers. Tokens are opaque values in the OAuth2 standard and can be implementer defined. The two actors that must agree on a token's form and content are the authorization server that produces a the token, and the resource server that uses the token's value to grant or deny a client's access to resource owner data.

A token must be recognized by a server as one of these forms before it can be used:

• Authorization token
• Self-contained access token (also known as an ID token, or identity token )
• Random access token
• Refresh token
• Bearer token

Authorization token

An authorization token is a random data value issued by an authentication server to a client who then sends it to an authorization server and exchanges it for an access token (self-contained or random).

Self-contained access token

An OAuth2 self-contained access token is a base64-encoded data value that holds the resource owner’s identity and granted access rights (also known as scope). This form of access token can be used directly by a resource server’s authorization process to grant or reject access to services or data, because it contains the client identity, resource owner identity, and resource owner scope necessary to perform authorization. In most implementations the token is a JSON web token (see JSON Web Tokens (JWT) for more information), but the OAuth2 standard does not specify the token's actual format.

Self-contained access tokens are commonly issued by enterprise authentication services to clients that can use the token in multiple resource servers. As explained in OAuth2 concepts and terms, a resource server is an abstraction that refers generally to any system or component that stores resource data and returns it to a client that is authorized to receive it. Authorization is determined by the access token that is sent by the client. It is the responsibility of the resource server to limit the authentication services from which it accepts access tokens by validating the token before it may be used.

The general guideline states that an authorization server may issue a self-contained access token directly to trusted clients who send it to the resource server, in each service request, as a bearer token. The resource server's authorization process validates the self-contained access token's authenticity, and then uses the token's identity, or access right values, to grant or reject access and add to the service's audit trail.

Some authorization servers support a request from a resource server to exchange an untrusted client-supplied random access token for a self-contained access token that contains the resource owner's identity and granted scope. In such a case, the resource server logs in to the issuing authorization server and exchanges the random access token for a self-contained access token. This is a much more complex, non-standards based process and is not widely available.

The method that is used by a resource server to obtain a self-contained access token is determined by the authorization server’s configuration and implementation according to the type of registered client. In both use cases, the resource server must obtain and fully validate a self-contained access token for expiration and data integrity before it grants access to resource owner data.

Random access token

An OAuth2 random access token is a unique Base64-encoded random data value that is typically issued to untrusted clients. Random access tokens are commonly used when an authorization server coexists with one or more resource server services in the same product. The randomness of the access token's value reduces the risk of the resource owner’s identity and access rights being stolen by the client application code. Random access tokens work because the authorization server and the resource server share the same (internet) network and storage of self-contained access tokens.

However, because the random access token does not contain a client identity, or a resource owner's identity, or granted data rights, a resource server cannot simply use the token to grant access to a resource owner's data. Before an exchange of a random access tokens can take place, the resource server and authorization server must first establish a trust relationship whereby each trusts the other to not compromise any access tokens. The trust relationship can be established several different ways, and is not specified as part of the OAuth2 specification. Examples of a trusted relationship between an authorization server and resource server may be the use of a SQL database, in-memory storage, or a fully authenticated HTTP login.

Refresh token

An OAuth2 refresh token is a unique Base64-encoded random data value that can (optionally) be issued by an authorization server in conjunction with a random or self-contained access token. To minimize the time a random or self-contained access token may be used after being stolen by a third party, an access token’s expiration times can be kept very short. To not overly burden the resource owner with continually re-authenticating to obtain a new non-expired access token, an authorization server can be configured to issue a refresh token, which the client application can use to automate the process of obtaining a new access token from the authorization server when the current one has expired.

The automated OAuth2 refresh token process typically takes place in the client when the resource server returns an expired token status. The resource server detects access token expiration only when an expiration value is present in the token and returns only a token expired error to the client. The resource server does not play a role in the client obtaining a new access token. The client, upon detecting an expired token response from the resource server, enters into a refresh flow with the authorization server to obtain a new access token.

Bearer token

A bearer token refers to any form of identity token that is sent by a client to a resource server using an HTTP authorization header that identifies the authorization-scheme as bearer. The token value of the bearer token authorization header is not defined. However, in most cases the value is an OAuth2 self-contained access token, or a simple JSON Web Token (JWT).

Example: "Authorization: Bearer abc6324.dgwyuio269nnnwllllsyyyyy.sssy2ajklyuiowl6789"