Who holds the ticket: OAuth 2.0 roles and bearer token verification

Delegated authorization without sharing passwords

Before OAuth 2.0 (RFC 6749 and RFC 9700 Best Current Practice), if an engineer wanted a third-party calendar or telemetry dashboard app (OAuth client C7) to read their messages on a mail or telemetry API, the app had to ask for the engineer’s raw password. Sharing passwords gives the client app unlimited power, breaks multi-factor authentication, and forces a full password reset to revoke a single integration.

OAuth 2.0 replaces password sharing with delegated authorization: the Resource owner authorizes the Authorization server (RiverAuth) to issue a bounded, time-limited access token to the Client (OAuth client C7), which then presents that token to the Resource server (mail-api). Under modern OAuth 2.0 security best current practice (RFC 9700), the legacy resource owner password credentials grant must not be used, and browser applications must not use the implicit grant.

Tracing API token presentation and the three refusal paths

The interactive figure below starts after the initial grant flow has completed and OAuth client C7 already holds a bearer token in memory (notice how the client treats each token as opaque, and no browser executes cryptography here). Follow the primary track first: OAuth client C7 sends an HTTPS request carrying token T1 to mail-api. The resource server verifies the cryptographic signature and issuer (RiverAuth), confirms the target audience (mail-api), checks the clock (exp valid with no-leeway expiry enforcement), and verifies scope (M7 read allowed) before returning the protected response (E7 copy received).

Now step through the three failure variants (audience, expiry, and issuer). In the audience variant, a token validly signed by RiverAuth for a different service (notes-api) is presented to mail-api; even though the signature is genuine, mail-api refuses it because aud does not match. In the expiry variant, notice the crucial distinction between expiration and bearer reuse: an ordinary bearer token is reusable until exp and is not automatic one-use, nor does presenting it prove which human is currently sitting at the keyboard. Anyone who steals a valid bearer token before exp can replay it unless sender-constrained tokens (mTLS or DPoP) are used. In the issuer variant, a token claiming foreign issuer LakeAuth is rejected immediately at the issuer gate, so downstream audience, clock, and scope claims are Not evaluated.

Containing bearer theft: short lifetimes and sender-constrained tokens

A standard Authorization: Bearer token works like a movie ticket. Whoever holds the string gets in until the clock expires. Engineering teams contain token theft in two ways. First, keep access token lifetimes short (a few minutes for high-risk APIs, RFC 6819) so an exfiltrated token ages out quickly. Second, for high-sensitivity APIs at Meridian Space & Robotics (chronos.orbital), bind the token cryptographically to the client’s TLS certificate (OAuth mTLS, RFC 8705) or an application key pair (DPoP, RFC 9449) so a stolen token string is useless without the holder’s private key.