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.

Note: The server that produces the OAuth2 token is a third-party implementation. The tokens cannot be generated from the OpenEdge environment

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
  • Identity token

Authorization tokens

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

Self-contained access tokens

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, but the OAuth2 standard does not specify the token's actual format. For more information, see About JSON Web Tokens.

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 About OAuth2, 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 can issue a self-contained access token directly to trusted clients that 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 tokens

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 use the token to grant access to a resource owner's data. Before an exchange of 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 in several ways, and is not specified as part of the OAuth2 specification. Examples of a trusted relationship between an authorization server and resource server are 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 can 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. When the client detects an expired token response from the resource server, enters into a refresh flow with the authorization server to obtain a new access token.

Bearer tokens

A bearer token refers to any form of access token that is sent by a client to a resource server using an HTTP authorization header that identifies the authorization scheme as a 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). Tokens can either be opaque or non-opaque.

Non-opaque tokens are encoded. Any web decoder can view the contents of a non-opaque token. Example: "Authorization: Bearer abc6324.dgwyuio269nnnwllllsyyyyy.sssy2ajklyuiowl6789"

Opaque tokens are more secure because they use a proprietary format. Opaque tokens require remote validation by the authorization server that created them. Example: "Authorization: Bearer lmr7281911wb83128cbl628lm0728ajkly711tsmmew6724831"

Identity token

An identity token in OpenID Connect configurations provides additional user information to a client applications. These details may include fields commonly used data for auto-filling forms for example email, address, and phone number. As the resource server, PAS for OpenEdge does not have direct access to an identity token. Using properties, you can configure PAS for OpenEdge to request identity token details from an endpoint on the authorizations server.