Access tokens are crucial tools for enabling secure access in decentralized systems. Having all of our digital tools and resources spread across the globe creates all manner of complexities, ranging from data governance to proof-of-identity, all of which become more confusing when not constrained to a time or place.

Access tokens can also solve the sometimes contradictory needs for enhanced security in an increasingly API-driven world. When used correctly, access tokens can greatly reduce the likelihood of data breaches due to leaked API keys, for example. Access tokens are increasingly recommended as a best practice within security workflows.

With such a rising demand, many different types of access tokens have emerged to fill the need. With that in mind, we’ve compiled a complete guide to access tokens to help you decide which will be best for your identity management and decentralized workflows.

The Main Types of Access Tokens

Access tokens can refer to many different resources. In their broadest sense, an access token is any code that authorizes a user and establishes the extent of their permissions. Once they’re received, a resource server verifies the access token and grants access for the specified duration. This duration is usually very short for security reasons. Sessions can be extended by using a refresh token to obtain a new access token without requiring the user to log in again.

Access tokens can range widely in complexity. Bearer tokens are the most rudimentary, as they’re the digital equivalent of the key to your front door. They’ve got the same problems and limitations as physical keys, too. If someone gets a hold of a bearer token, they’ll have the same access as the official recipient.

Sender-constrained tokens are more secure while operating on a principle similar to access tokens. For sender-constrained tokens, the access token is bound to the client’s identity, preventing unauthorized reuse.

ID tokens serve a different purpose — proving who the user is. Using OpenID Connect, ID tokens are issued as JSON Web Tokens (JWTs) containing numerous properties associated with the user, all of which can be configured by the authorization server. JWTs are web tokens encoded in Base64URL format consisting of three segments: the header, the payload, and the signature. Each of these segments is separated by a period. An example of a JWT might look like:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.
eyJjbGllbnRfaWQiOiJZekV6TUdkb01ISm5PSEJpT0cxaWJEaHlOVEE9IiwicmVzcG9uc2VfdHlwZSI6ImNvZGUiLCJzY29wZSI6ImludHJvc2NwZWN0X3Rva2VucywgcmV2b2tlX3Rva2VucyIsImlzcyI6ImJqaElSak0xY1hwYWEyMXpkV3RJU25wNmVqbE1iazQ0YlRsTlpqazNkWEU9Iiwic3ViIjoiWXpFek1HZG9NSEpuT0hCaU9HMWliRGh5TlRBPSIsImF1ZCI6Imh0dHBzOi8vbG9jYWxob3N0Ojg0NDMve3RpZH0ve2FpZH0vb2F1dGgyL2F1dGhvcml6ZSIsImp0aSI6IjE1MTYyMzkwMjIiLCJleHAiOiIyMDIxLTA1LTE3VDA3OjA5OjQ4LjAwMCswNTQ1In0.IxvaN4ER-PlPgLYzfRhk_JiY4VAow3GNjaK5rYCINFsEPa7VaYnRsaCmQVq8CTgddihEPPXet2laH8_c3WqxY4AeZO5eljwSCobCHzxYdOoFKbpNXIm7dqHg_5xpQz-YBJMiDM1ILOEsER8ADyF4NC2sN0K_0t6xZLSAQIRrHvpGOrtYr5E-SllTWHWPmqCkX2BUZxoYNK2FWgQZpuUOD55HfsvFXNVQa_5TFRDibi9LsT7Sd_az0iGB0TfAb0v3ZR0qnmgyp5pTeIeU5UqhtbgU9RnUCVmGIK-SZYNvrlXgv9hiKAZGhLgeI8hO40utfT2YTYHgD2Aiufqo3RIbJA

Access Token Formats

While the authorization server often determines the specification of an access token, the format has a greater impact on design and usage.

Opaque tokens are random strings of characters generated by the authorization server. This prevents public applications from leaking sensitive data, as no data is exchanged. Opaque tokens can be used indiscriminately, as they don’t risk revealing personally identifiable information (PII). An example of an opaque token could look like 979645b3-aac3-563f-b27d-111777866aa7.

When a resource server receives an opaque token, it will often trigger an introspection flow. This introspection flow generally calls a separate API, which assesses when an opaque token was issued.

Combining Token Types

Both opaque tokens and JWTs have their strengths and weaknesses. However, using them together can make the most of each format while overcoming their shortcomings. Combining JWTs with an opaque token is known as a phantom token pattern, where an API gateway or reverse proxy server inspects the JWT for an opaque token that can be sent to an upstream app or API.

The split token pattern performs a similar function using only the JWT. Instead of issuing a separate opaque token, the split token pattern uses the signature of a JWT as the opaque token, which is hashed and then re-combined with the header and body. This hashed signature is then cached, using the signature as the API key to store the rest of the information. This eliminates the need for introspection. The authorization server will need to put the pieces together fairly quickly, however, or you run the risk of the connection timing out.

Token handlers are another hybrid design pattern for access tokens, mainly meant for single-page applications (SPAs). Due to privacy concerns, many browsers are making it difficult to work with third-party cookies. To contend with this fact, a token is sent to the token handler, which is installed on a gateway or proxy server. When the token handler receives a token, it sends a secure cookie along to the SPA.

Best Practices for Dealing With Access Tokens

There are a handful of industry best practices for working with access tokens. For instance, access tokens should be stored in memory rather than in local storage or session storage since both of these can be susceptible to XSS attacks.

Next, proper encryption matters. You should always use HTTPS when transmitting tokens. Otherwise, you risk having them intercepted by unauthorized users. Proper encryption adds a layer of security should your token still somehow be intercepted. Encryption algorithms like AES or RSA are widely used to secure tokens during transmission and storage.

Lastly, you should manage expired tokens properly. If a token expires during a user’s session, you should use a refresh token to obtain a new one. A new refresh token should be issued along with the new access token to disrupt the user as little as possible. Typically, the goal is a silent refresh to avoid user disruption, but logging in again is a fallback if the refresh fails. This way, your data will remain secure while keeping user frustration to a minimum.

Final Thoughts on Access Tokens

The world gets increasingly API-driven with each passing year, especially in the wake of AI. Unfortunately, APIs also tend to be one of the less secure components of a network, which means that poorly secured APIs increase the likelihood of a data breach or similar cybersecurity incident.

It’s vital that you build safeguards into your network following patterns like decentralized identity management or zero-trust architecture. It’s important to become acquainted with access tokens and learn to use them to maximum effectiveness if you want to ensure your data is secure and your API performs as well as it can.