The different types and formats of tokens explained – The New Stack


Jonas Iggbom

Jonas is Director of Commercial Engineering at Curity. His expertise lies in identity and access management, and access control solutions for privileged users, databases and applications.

When building security solutions using OAuth and OpenID Connect (OIDC), we frequently discuss tokens. Sometimes these systems are even called token-based architectures.

Tokens play a central role in authorizing access to applications, services, and APIs. They also enable secure, flexible and scalable access management. Using tokens means apps don’t have to keep a static API key or, even worse, keep a username and password.

The type of token used in a given scenario is often not explicitly described, but more or less assumed. Different tokens serve different purposes and should be used appropriately for each use case.

Let’s take a look at some of the different token formats and types.

Types of tokens

Access tokens

The access token (AT) is perhaps the most common type of token. A user or service authenticates in some way and the authorization server (AS) issues an access token. Depending on the configuration of the AS, this token is typically an opaque token. Or, it can be a JSON Web Token (JWT).

The application typically uses the access token to identify the user or service. The lifetime of these tokens is usually very short for security reasons. If an attacker obtains an access token, it can be used to gain access as the user or service it was issued to. This could present challenges in specific architectures, such as a Single Page Application (SPA) that cannot protect the token adequately. One approach to solving this problem is the token manager pattern.

Bearer tokens

The most common way to use access tokens is as bearer tokens. This means that the bearer of the token will be granted access. With this type, the application or API receiving the token does not verify that the correct sender presented the token. Therefore, a token could be hijacked by an attacker and used to access an application. Using bearer tokens places more demands on the application to properly protect the token.

Sender Constrained Tokens

The authorization server may use cryptographic information when issuing the token to bind the token to the application. This creates a pairing between something that only the application knows (cryptographic keys) and the given token. Since the token is sender-constrained, these are called sender-constrained tokens, also known as proof-of-possession tokens. The article “Mutual TLS Sender Constrained access tokens” explains how these tokens are issued.

For example, when the application sends the token to an API, it also sends information about the cryptographic key. The API can then validate that the presented token is linked to the cryptographic key which is also given. This protects the token against theft and reuse. Although sender-limited tokens require additional configuration around cryptographic keys, they are certainly worth it.

Refresh tokens

When access tokens are issued to users, they require an authentication step. But, short-lived tokens could be a significant inconvenience for the user as they constantly have to re-authenticate to get a new active token. This is where refresh tokens can help.

At the time of issuing an access token, the authorization server may also issue a refresh token. When the AT has expired and a new one is needed, the application can invoke a refresh token flow and present the refresh token to get a new refreshed AT. In this flow, the user does not need to re-authenticate.

Identification tokens

Unlike the Access Token and Refresh Token, an ID Token is always a JSON Web Token (JWT). The ID token represents the user’s identity or the user’s authentication information. It is issued as part of OIDC streams when the openid range is requested.

The ID token can contain several properties associated with the user for whom the token is issued. These properties and their values ​​are defined and configured in the authorization server and can be consumed by the receiving API.

In addition to user-specific properties, the ID token also contains a set of standard properties or claims. These can identify, for example, who issued the token, who the token is for when it expires, and other attributes.

Token Formats

In many cases, the exact format of the token is not specified by the standard — instead, the authorization server dictates the format. Sometimes this can be configured depending on the application requesting a token.

As mentioned earlier, the ID token format is a JWT defined by the OIDC standard.

Opaque tokens

Opaque tokens, also called referral tokens, are unique random strings generated by the authorization server. Typically, access and refresh tokens are opaque and therefore do not pass any data to the application or API. This helps prevent public applications from potentially disclosing the information contained in the token. An opaque token can be transmitted without the risk of revealing personally identifiable information (PII) about the user.

However, a system may require more detailed information to publish data from an API or inform application behaviors. In this case, introspection must be performed on an opaque token. Introspection is a flow in which the token is sent to the authorization server’s introspection API. The API response then indicates whether the token is still valid and additional data determined when the token was issued.

Example of opaque token: 087258a5-ddb2-487e-a38e-071698896ff9

JSON Web Tokens (JWT)

JSON Web Token (JWT) is a popular token format. It consists of a header, body and payload, and a signature. The base64-encoded JWT format separates the three elements with a period. Here is an example :

The header contains metadata about the token and its encryption algorithms.

The payload is the actual data and contains sender, user, and user authorization information.

Finally, the signature is used to verify the integrity of the token and will ensure that the token has not been tampered with.

JWTs are great for persisting data and therefore well suited for ID tokens. Access tokens can also be issued as JWTs, but it depends on the use case if it is appropriate to do so. Remember that opaque tokens expose no information and must be introspected to reveal their contents. JWTs, on the other hand, can contain a lot of data that is not hidden.

The downside is that JWTs can potentially contain easy-to-read PII. This is true for the most basic use of JWTs, where they are unencrypted and are simply protected against tampering. For example, you might be able to determine if the information in the JWT has changed. But to prevent data from being read, the JWT must be encrypted. Wherever JWTs are used, best practices for securing JWTs should be followed.

The best of both worlds

The different token formats have advantages and disadvantages. JWTs are great because they can potentially contain all the required data, but they run the risk of data leakage. Opaque tokens, on the other hand, hide this data and the authorization server must introspect the tokens to reveal the data. The Phantom Token model and the Split Token model combine these token formats and offer the best of both worlds.

Ghost Tokens

The Phantom Token model combines a JWT and an opaque token issued to the (public) application. With the use of an API gateway or reverse proxy, the opaque token is then introspected (exchanged) for a JWT that can be passed to the upstream API for consumption. With this approach, the API receives a JWT with all the data it needs to authorize the caller and the information to post. But the public application does not receive the PII which may accidentally leak.

This process involves introspecting the opaque token, but the JWT in the response can be cached in the gateway for later use. This could help optimize performance, especially if multiple APIs are called.

Shared tokens

Split tokens are similar to shadow tokens in that they prevent the JWT from being available to a public client. However, the model adopts a different process. Instead of issuing an opaque token, the authorization server sends the signature of the JWT to the public client. This fulfills the purpose of the opaque token in the shadow token approach, and the client uses it as an access token.

When sending the signature to the client, the authorization server simultaneously hashes the signature and sends it along with the full JWT header and body to an API gateway cache. The hashed signature is stored as key information to retrieve the rest of the token, head and body.

When the API Gateway receives an incoming request in which the signature is presented as a token, the API Gateway hashes the signature. It looks for the rest of the token in its cache using the hashed signature as the key. It then assembles the complete token and passes it to the API.

In this case, no introspection is necessary. However, the authorization server needs to push the parts of the token to the cache quickly enough so that the API gateway doesn’t encounter a cache miss when receiving a request.

Token manager

The token manager is not specifically a type of token, but it is worth mentioning because it is strongly related to some of the most common issues with protecting a token in single-page applications. Browsers are making it increasingly difficult to manage third-party cookies due to tracking prevention. SPAs are also unable to securely protect a token in a manner similar to secure cookies.

Instead of tokens being issued directly to the SPA, the token is issued to a token manager installed on a gateway/proxy. The token manager then sends a secure cookie to the SPA which can be used instead of a token. When the SPA needs to make an API call, it sends the secure cookie and the token manager replaces it with the actual token when the request is passed to the API.

Refer to this “Token Manager Overview” for more details on this approach.

Feature image via Pixabay.

Source link


Comments are closed.