In the real world
Let's start with a real-world analogy. Imagine a flight ticket you previously bought as an access token authorising you to board the plane for your trip. On the other hand, an ID card functions as your ID token, a document that proves an authority has authenticated your identity. Another example could be a concert ticket, your access token to the event, and your driver's license, your ID token.
Just as you can't board a plane with only your ID card without buying a flight ticket, you can't use the ticket to prove your identity. Like cards and tickets, both tokens are created to serve specific purposes.
In the context of our analogy, the access token is your right to board the plane, while the ID token is your proof of identity. Using the person's name of the flight ticket bearer and proving that the name identifies you makes your intent to board the plane legit and authenticated.
ID vs Access
In the digital world, ID tokens are your digital identity, a secure container that holds all the information you agree to share with the identity authority. They're a digital version of your ID card. Just as you present your ID card to authenticate your identity, the entity initiating the authentication process uses ID tokens to retrieve authenticated identity details.
Access tokens are not just proof of authorisation but the key to your digital world. They contain identity references for the user and the software authorised to access a specific service. This proof of authorisation is forged by evaluating the identity intent, is valid for a certain period, and is closely linked to service usage only.
The ID tokens concern the user authentication process, demonstrating how the system knows you, while Access tokens concern an authorisation decision proving that the intent has been authorised.
How are authenticated ID cards?
When you present your ID card on request, it tends to authenticate you as the identity claimed by your ID card, representing proof of ownership. The verifier checks if the ID card looks legitimate to forge a proof of authority and compares the associated picture with you in person, acting as proof of life.
In essence, the ID card "distributed" authentication process is based on the following:
- It looks legit (valid symbols, colours, format, etc.)
- The picture looks like the bearer's face
- The card has not expired
The term 'distributed' here refers to the fact that the authentication process is not solely dependent on one factor but rather a combination of factors, making it more secure and reliable.
To build trust around an ID card, you must create a card that looks legit to bypass the proof of authority, change the picture to ensure the holder looks like the associated picture, and ensure it's not expired.
How are authenticated ID tokens?
In the digital world where ID cards are translated as ID tokens, you will reduce the 'distributed' authentication process to 'it looks legit', meaning the token is cryptographically signed with a key from a trusted authority who delivered the ID token.
In other words, the authentication process is 'distributed' because it relies on multiple factors, such as the token's legitimacy and the authority verifier trust that issued it, to verify the user's identity.
The authentication process uses:
- A cryptographic signature verification
- The token is usable (expiration, type, etc.)
To build trust around an ID token, you must ensure that you can sign it with one of the private keys associated with public key trust. By definition, an ID token is vulnerable to bearer spoofing, as it's not possible to provide an equivalent to a picture matching check like for an ID card to authenticate the bearer.
The purpose of ID tokens is to authenticate an identity by trusting the authority who generated it.
How are authenticated Access tokens?
Access tokens are opaque tokens, meaning they should not have any meaning for the software that received them as proof of authorisation.
The access token represents a sealed authorisation decision valid for a given time and associated with a validated intent.
The authentication process uses:
- Proof of authority knowledge
- A cryptographic signature verification
- An identity cryptographic binding
- The token is usable (expiration, type, etc.)
- The token matches the expected intent
To build trust around an opaque Access Token, you must ensure the token is known by the authority that forged it. Using digital signature verification to prove the token provenance only proves that the private key used to sign the token is the same as the authority. This weakness is why many providers don't use rich tokens but simple pseudo-random strings as access tokens. To mirror the ID card picture-based comparison check, an Access Token can have an identity binding to confirm that the access token owner and the client using it are legitimate. The token is also subject to acceptance time and intent validation to ensure that it is used in the appropriate context that represents the proof of authorisation.
The purpose of an access token is to authenticate an authorisation decision.
Why is using ID tokens as proof of authorisation, not a good idea?
Let's consider that you are authorising people based on their ID card information only:
- How would you prove to the boarding control that you paid for this flight?
- What can happen if someone steals your ID card and looks like you?
Building an authorisation model solely based on claims identified in the ID Tokens can immediately expose you to the risk of identity spoofing and authorisation bypass. We saw that ID Tokens act as proof of authentication and don't serve an authorisation purpose. When you use ID Tokens as service access authorisation tokens, you open your service to identity impersonation. Secondly, it forces you to distribute your authorisation policy to each service that consumes your ID Tokens as you evaluate the access decision based on the presented identity just in time.
This vulnerability occurs when you lack 'bearer authentication', similar to the picture on your ID card. Bearer authentication means that the token holder is considered the legitimate bearer of the token, which is why it's called bearer authorisation. This flaw is similar to API key authentication, which is, in fact, an API Key bearer authorisation. The identity is not proven but trusted by data associated with the provided token. Merely presenting API keys or ID Tokens is enough to authenticate as a legitimate bearer, posing significant security risks that you must be aware of.
For example, if someone gets hold of your API Key or ID token, they could pretend to be you or access your private data without permission. This emphasises the significance of comprehending and safeguarding your tokens and using the correct type for the intended purpose.
Conclusion
A lot of the confusion arises from the fact that we can utilise the same technical encoding for both tokens in the digital realm. However, even if we use JWT for both, with shared claims, each token is constructed for a specific purpose.
Use ID Tokens for authentication-related use cases only
- Transfer identity from authority to client
- Transfer identity from client to another authority for federation
- Exchange your identity to another token
Use Access Tokens for authorisation-related use cases only
- Access a service/resource
- Represent an intent authorisation decision
In conclusion, understanding the crucial difference between access and ID tokens is essential for securely navigating the digital world. Access tokens serve as proof of authorisation and are linked to specific services, while ID tokens authenticate a user's identity and are equivalent to digital ID cards. Both tokens undergo authentication processes, with access tokens focused on sealed authorisation decisions and ID tokens utilising cryptographic signatures to verify legitimacy. By grasping the distinct roles of these tokens, individuals and organisations can enhance security and data protection in the digital space.
More about this topic
- ID Token and Access Token: What's the Difference?
- ID Tokens vs Access Tokens
- I don’t like Identity Tokens
Photo by Amir Hanna on Unsplash
Top comments (0)