Access Token.

An access token represents the authorization a resource owner has granted to a client, scoped to specific permissions and audiences. In OAuth 2.0 (RFC 6749) and OpenID Connect, access tokens may be opaque — validated by calling the authorization server's introspection endpoint (RFC 7662) — or self-contained JWTs validated locally by signature. They are typically sent in the Authorization: Bearer header per RFC 6750 and must travel over TLS.

The core weakness of a plain bearer token is that possession equals authority: a token stolen from browser storage, a log, or a proxy can be replayed by anyone. This drove the rise of sender-constrained tokens. RFC 8705 binds a token to the client's TLS certificate (recording its hash in the cnf.x5t#S256 claim), and RFC 9449 (DPoP) binds the token to a client-held key pair, requiring a fresh signed proof JWT on every request so a replayed token is useless without the private key. Token-theft attacks — including the session/token replay seen in Lapsus$ and various "pass-the-token" cloud intrusions — are precisely what these mechanisms defeat.

Best practice: short lifetimes (minutes), narrow scopes, strict audience and issuer validation, rejecting the alg: none JWT trick, pairing with refresh tokens for renewal, and keeping tokens out of JavaScript-accessible storage. For high-value APIs, prefer DPoP- or mTLS-bound tokens over plain bearer tokens.

flowchart LR
  RO[Resource owner] -->|grants consent| AS[Authorization server]
  C[Client] -->|token request + DPoP/mTLS key| AS
  AS -->|short-lived access token<br/>scope + aud + cnf claim| C
  C -->|Bearer token + proof of possession| RS[Resource server / API]
  RS -->|validate signature/introspect<br/>check aud, exp, key binding| RS
  RS -->|allow or deny| C