Bearer Token
Overview
A Bearer Token is a long-lived token that belongs to an authorized entity following authentication. But, there are some important details to note in order to utilize this temporary derivative of the data it provides access to effectively and securely. The term temporary derivative is accurate because:
- Temporary: Bearer Tokens should have an expiry (i.e. Time-To-Live — TTL).
- Derivative: Bearer Tokens are a secondary product of the actual product (the data they provide access to).
The Bearer Token’s authentication occurred at the beginning of the token’s life, and its TTL could be hours, if not days. This results in a security vulnerability for the rest of the duration of that token, because it could fall into the wrong hands.
Table of Contents
History
The core principle of Bearer Tokens emerged in the financial system. The concept has been used in various forms for physical securities and documents long before digital applications.
Subsequently, this principle began to be adapted for use in digital systems, but there wasn’t necessarily a prefixed Bearer to a header as there is today. In the early 2000s, one adopter of a token mechanism to signify identity and access rights was SOAP. Their tokens function with a similar principle as Bearer Tokens today.
Today, Bearer Tokens are predominantly associated with OAuth.
Security
Being that Bearer Tokens are a mechanism to provide secure access to resources, it’s important to understand their vulnerabilities, and how to use them securely.
TLS Vulnerability
TLS 1.2 is used predominantly today all over the internet. However, it has a relatively serious vulnerability (given the scale of its use). First, learn more about how the TLS handshake works.
The vulnerability in TLS 1.2 was addressed in 1.3, but most of the internet still uses 1.2. The issue exists in the long-lived symmetric private key that is exchanged during the key exchange phase of the TLS protocol. In TLS 1.3, this symmetric private key is not the same from one session to the next, so if it’s compromised in one session, subsequent or previous sessions cannot be decrypted.
XSS (Cross-Site Scripting)
Bearer Tokens should not be stored in plain browser caches. They should be stored securely in browser cache (so that JavaScript scripts cannot access them) and only transmitted through HTTPS. This can be accomplished by setting the Set-Cookie response header from the server with HttpOnly, Secure flags.
Implicit Authentication
In a near-perfectly secure world (perfectly secure does not exist), each request for resources would carry with it a unique authentication challenge to validate identity. Without this, it’s possible for an adversary to gain access to a long-lived authorization token like a Bearer Token (using it as they wish), thanks to its insecure implicit authentication.
As it currently stands, Bearer Tokens are implicitly used for authentication (because of their reusability). This means that the owner’s identity is assumed to be validated through the presence of a valid Bearer Token upon subsequent usages.
Conclusion
Bearer Tokens have a long history, and it may be coming to an end. With the recent advent of Zero-Knowledge Proof that enables sophisticated authentication where a user’s credentials never leave their machine (instead sending a one-time proof that is not replayable), the static nature of Bearer Tokens as they exist today appears more and more dated in the world of security. However, making the move to Zero-Knowledge Proof for something as common as Bearer Tokens would require a significant increase in computational capacity.
Updated: 2024-02-08
Author
Sam Malayek works in Vancouver, using this space to fill in a few gaps. Opinions are his own.