Bearer tokens are replayable by design. Learn how token binding (DPoP, mTLS) reduces replay risk and the tradeoffs involved.
Key concepts
- Spec vs implementation: standards define interoperability; products differ in defaults and edge cases.
- Trust boundaries: know who issues tokens/assertions, who validates them, and what data crosses boundaries.
- Profiles and best practices: real-world deployments typically require extra constraints beyond the base spec.
- Operational reality: key rotation, retries, time skew, observability, and safe failure modes matter as much as the protocol.
A practical mental model
- Start with actors (clients, servers, identity providers, resource servers).
- Identify artifacts (tokens, assertions, credentials, metadata).
- Define verification (signature validation, audience checks, issuer checks, nonce/state, replay defenses).
- Define lifecycle (issuance, rotation, revocation/expiration, recovery).
Examples
- Debug with concrete artifacts:
- Capture a request/response and identify each parameter’s purpose.
- Inspect tokens/assertions (claims, audience, issuer, timestamps).
- Confirm key material and rotation strategy (JWKs / certificates).
Common pitfalls
- Treating tokens as “opaque magic” instead of a verifiable contract.
- Not validating issuer/audience/expiry/signature rigorously.
- Missing replay protections (especially in mobile/SPAs) and unsafe redirect URI handling.
- Underestimating operational issues: clock skew, retries, and partial failures.
Where to go next
- Access Management: /category/access-management
- CIAM: /category/ciam
- IGA (provisioning & lifecycle): /category/iga
- AppSec concepts: /topic/specifications/jwt-and-jose-jws-jwe-jwk-the-token-toolbox
- Identity for AI: /category/identity-for-ai