Sender-Constrained Token.
An OAuth access or refresh token bound to a specific client via a cryptographic key — useless if stolen without the corresponding key. Implemented via mTLS (RFC 8705) or DPoP (RFC 9449).
Sender-constrained tokens are the production-grade defense for high-value OAuth deployments — agent identity, financial services, healthcare. The setup cost is real (client key management, resource-server verification) but the security improvement is structural: pure-token theft becomes a non-issue. The 2026 trajectory is toward sender-constrained as the new default for any OAuth client whose token leak would be material.
Common questions
What's the difference between sender-constrained tokens and bearer tokens?
When should I use mTLS vs DPoP?
Is FAL3 equivalent to sender-constrained?
Related terms
In the guides
mTLS Explained: Mutual TLS for Service Identity and API Authentication
Mutual TLS authenticates both sides of the connection. How it works for service-to-service, where SPIFFE/SPIRE fits, and the cert-management pitfalls that bite.
OAuth 2.1 Explained: What Changed and Why It Matters
OAuth 2.1 consolidates fifteen years of OAuth 2.0 practice into a single coherent specification. What it deprecates, what it requires, and how to migrate existing OAuth 2.0 code.
Token Management for AI Agents: Lifetimes, Rotation, and Revocation at Machine Speed
Agent tokens are stolen faster and used harder than human tokens. How to set lifetimes, rotate refresh tokens, scope per-tool, and detect anomalies in production agent deployments.