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 Resources Server that uses the token's value to grant/deny access to Resource Owner data. to a Client.

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

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).

An OAuth2 Self-contained Access Token is a base64 encoded data value that holds the Resource Owner’s identity and granted access rights (aka scope). This form of Access Token can be used directly by a Resource Server’s authorization process to grant/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 used by Federated Authentication services who exist to authenticate users and issue a single Access Token that may be used by multiple vendor's Resource Server services. It is the responsibility of the Resource Server to limit which Federated Authentication service(s) it will accept Access Tokens from by validating it before it may be used.

The general guideline states that an Authorization Server may issue a Self-contained Access Tokens directly to trusted Clients who sends it to the Resource Server in each service request as a Bearer Token. The Resource Server's authorization process will validate the Self-contained Access Token's authenticity, and then use the token's identity or access right values to grant or reject access and add to the service's audit trail.

Some Authorization Servers will 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 would log into into the issuing Authorization Server and exchange 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.

Which method 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 will grants access to Resource Owner data.

An OAuth2 Random Access Token is a unique Base64 encoded random data value that is typically issued issued to untrusted Clients. Random Access Tokens are commonly used when an Authorization Servercoexists 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 Clientapplication 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, Resource Owner's identity, or granted data rights, a Resource Server cannot simply use it 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 Token. The trust relationship can be established a number of different ways, and is not specified as part of the OAuth2 specification. Examples of a trusted relationship between an Authorization and Resource server may be the use of a SQL database, in-memory storage, or a fully authenticated HTTP login.

An OAuth2 Refresh Token is a unique Base64 encoded random data value that may [optionally] be issued by an Authorization Server in conjunction with a Random/Self-contained Access Token. To minimize the time a Random/Self-contained Access Token may be used after being stolen by a 3rd party, an Access Token’s expiration times may be kept very short. To not overly burden the Resource Owner with continually re-authenticating in order to obtain a new non-expired Access Token, a Authorization Server may be configured to issue a Refresh Token, which the Client application may 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 would typically take place in the Client when the Resource Server returns an expired token status. The Resource Server only detects Access Token expiration when an expiration value is present in the token and will only return 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 will enter into a Refresh flow with the Authorization Server to obtain a new Access Token.

A Bearer Token refers to any form of identity token that is sent by a Client to a Resource Server via 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"