Bearer tokens vs sender-constraining tokens: Why possession alone isn't enough
Blog post from WorkOS
Bearer tokens have long been a staple in web authorization due to their simplicity, allowing access to anyone possessing them, but this simplicity comes with the risk of unauthorized use if the token is leaked. Sender-constraining tokens address this vulnerability by binding tokens to specific cryptographic keys, ensuring that possession alone isn't sufficient for access. Two main standards exemplify this approach: DPoP (Demonstrating Proof of Possession) and mTLS (Mutual TLS). DPoP, defined in RFC 9449, integrates key management into OAuth 2.0 workflows, requiring clients to prove ownership of a private key with each request, making token replay and theft ineffective. mTLS, on the other hand, leverages the TLS layer to bind tokens to client certificates, providing robust security but requiring more complex infrastructure. While bearer tokens are suitable for low-risk environments and scenarios prioritizing simplicity, sender-constraining tokens are crucial in contexts where tokens cross trust boundaries or are used in regulated industries. For most teams, implementing DPoP is a practical choice due to its compatibility with existing HTTPS protocols and support from major identity providers. As security requirements evolve, the choice between bearer and sender-constraining tokens hinges on the specific needs for security versus operational simplicity.