Wiki · Concept · Last reviewed June 25, 2026

OAuth Bearer Token Usage

OAuth bearer token usage is the RFC 6750 pattern for presenting access tokens to protected resources, replay-sensitive when agents or logs touch token strings.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: agents, authorization, OAuth, bearer tokens, credential custody, audit trails

Definition

OAuth bearer token usage is defined by RFC 6750, The OAuth 2.0 Authorization Framework: Bearer Token Usage, an Internet Standards Track RFC by Michael B. Jones, Dick Hardt, and David Recordon published in October 2012. It describes how a client uses an OAuth 2.0 access token in HTTP requests to reach a protected resource.

A bearer token is possession-based. RFC 6750 defines it as a security token that any party in possession of the token can use without proving possession of cryptographic key material. This is easy to deploy, but a copied token may become replayable unless other controls block the replay.

This entry treats RFC 6750 as the baseline pattern behind many API connectors. Entries on Sender-Constrained Tokens, OAuth DPoP, and OAuth Mutual TLS cover designs that add proof from the caller.

Mechanism

RFC 6750 defines three presentation methods. The normal method is the HTTP Authorization header with the Bearer scheme; resource servers must support it. The RFC also defines a form-encoded access_token body parameter under restrictions, and a URI query parameter method that it does not recommend because URLs are often stored, logged, cached, and shared.

The resource server can challenge a request with WWW-Authenticate: Bearer. RFC 6750 defines parameters such as realm, scope, error, error_description, and error_uri, with errors including invalid_request, invalid_token, and insufficient_scope. These fields separate malformed requests, expired or revoked credentials, and insufficient scope.

RFC 6750 requires TLS for bearer-token usage. RFC 6749 supplies the broader OAuth 2.0 framework in which a client obtains limited access, either for a resource owner or for itself, then uses the access token at protected resources.

Agent Context

Agent systems multiply token surfaces. A connector may obtain a token, a tool gateway may attach it to outbound calls, browser automation may hold it in session state, and logs may record request metadata. Prompt traces, crash reports, screenshots, support bundles, and developer consoles can accidentally turn a credential into content.

The practical rule is simple: do not pass bearer tokens into model context, user-visible transcripts, or general-purpose logs. Keep them in credential-handling components, redact request headers, log token fingerprints rather than values, and attach credentials at the last responsible boundary.

Bearer-token simplicity can fit low-risk APIs. The governance problem begins when the same ambient credential crosses agents, tenants, tools, and resource servers without a record of why it was minted and where it was accepted.

Governance Use

RFC 9700, the OAuth 2.0 Security Best Current Practice, updates RFCs 6749 and 6750 with later security guidance. For bearer-token deployments, governance should emphasize short lifetimes, precise scopes, audience restriction, TLS, leak-resistant logging, and sender-constrained access tokens for sensitive resources.

RFC 7662 defines token introspection, so a protected resource can query active state and metadata. RFC 7009 defines token revocation, so a client can report that a token is no longer needed. Together they support cleanup after a task, logout, account change, compromise, or incident response.

An agent audit record should preserve validation facts rather than secrets: issuer, client, subject class, resource audience, scope, token class, expiration, introspection result, revocation event, tool call, approval receipt, and final resource action.

Limits

A bearer token is not proof that the right human approved the action, that the current prompt is trustworthy, that the caller is the intended software component, or that a task remains within policy. It only says that the request presented a credential the resource server will honor.

Leakage is the central limit. If a bearer token appears in a prompt, HTTP log, analytics event, terminal transcript, browser extension, error report, or support archive, any party with that string may be able to replay it until expiration or revocation. Audience checks, short lifetimes, introspection, revocation, DPoP, mutual TLS, and least privilege reduce damage but do not erase the possession-based design.

Review Record

Source Discipline

Claims about bearer-token definition, HTTP presentation methods, challenges, error codes, and TLS requirements should cite RFC 6750. Claims about the wider OAuth authorization framework should cite RFC 6749. Modern security claims should cite RFC 9700. Claims about checking active state should cite RFC 7662, and claims about explicit token invalidation should cite RFC 7009.

Spiralist Reading

Spiralism reads the bearer token as a lesson in institutional memory: possession can be mistaken for legitimacy when systems are built for speed. The string works because the resource server accepts it, not because the surrounding context is sound.

For human-machine cognition, keep the token out of the model's imaginative space. The runtime should guard the credential, attach it narrowly, and leave a clear audit trail.

Sources

Return to Wiki