Loading post…
OktaAlisa DuncanTutorial
Elevate Access Token Security by Demonstrating Proof
Summary
Bearer access tokens let anyone holding a valid token call a resource server, creating risk when tokens are stolen. Existing protections include secure coding, short expiration, and origin restrictions, but the post presents OAuth 2.0 Demonstrating Proof of Possession (DPoP) as a way to bind tokens to client-generated cryptographic proof. The client creates a JWT containing request details, issue time, unique identifier, and public key; the authorization server uses it to bind a key hash and request information to the returned token. For sensitive requests, authorization or resource servers can require a nonce, prompting a new proof and limiting lifetime and replay risk. Resource servers must validate both proof and access token properties, with a vetted OAuth library recommended.
Context
Bearer tokens and static API keys grant access to whoever presents a valid token, so token theft can enable fraudulent API calls. The post contrasts existing safeguards with DPoP, which binds token use to a client’s cryptographic proof and can support confidential and public clients.
Approach / What changed
DPoP uses asymmetric encryption and JWT proofs to bind an OAuth 2.0 access token to a client public key and specific HTTP request information. Proofs include the request URI, method, issue time, unique identifier, and public key; authorization or resource servers can add a nonce for higher-security requests. Resource servers decode and validate the DPoP proof and access-token properties, preferably through a vetted OAuth 2.0 library.
Takeaways
DPoP is designed for both confidential and public clients, unlike client secrets, mutual TLS, and private key JWT methods described as applying only to confidential clients.
A DPoP proof JWT carries the request URI, HTTP method, issue time, unique identifier, and public key; the access token contains a public-key hash and request information.
A server-issued nonce forces the client to create a fresh proof for a sensitive request, while the unique identifier helps mitigate replay attacks within the proof’s validity window.
FAQ
How does DPoP prevent a stolen access token from being reused?
The client proves possession of a private key when creating the DPoP proof. The authorization server binds the token to the corresponding public-key hash and HTTP request information, limiting use to the client and request represented by the proof.
When does a nonce enter the DPoP flow?
An authorization or resource server may require a nonce for a high-security request. It rejects the request with a DPoP-Nonce header and an error, after which the client creates a new proof containing the server-provided nonce.
What must a resource server validate for DPoP requests?
It must validate properties in the DPoP proof’s JWT header and payload and verify properties in the access token. Opaque tokens may require the authorization server’s introspection endpoint, and the post recommends using a vetted, well-maintained OAuth 2.0 library.
Source and freshness
- Source
- developer.okta.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.