Bearer Token

A bearer token is the simplest, and by far the most common, kind of access credential on the web: a string that grants access to whoever presents it ("bears" it), full stop, no proof of identity, no cryptographic signature tying it to a specific holder, nothing beyond possession of the string itself. It's sent as a header on every request:

Authorization: Bearer eyJhbGciOiJFZERTQSIs...

The simplicity is the whole appeal: no per-request signing, no client-side cryptography, works identically from a curl command, a mobile app, or a browser. It's also the whole risk: a bearer token that leaks, into a log file, a misconfigured proxy, a browser extension with too much access, is just as usable by the thief as by its intended holder, for as long as it remains valid. That's the exact gap DPoP (see that entry) was written to close over a decade later, and it's why RFC 6750's own security considerations section spends real space warning implementers to keep bearer tokens off the query string, out of logs, and always over TLS.

Where it comes from

RFC 6750 was published in October 2012 by the IETF OAuth Working Group, authored by Michael B. Jones and Dick Hardt, published in the same batch of documents, and by some of the same hands, as OAuth 2.0's core framework itself (RFC 6749). It's worth reading alongside the OAuth 2.0 entry's note on Eran Hammer's resignation: bearer tokens, secured by TLS alone rather than by cryptographic request-signing, were specifically what he argued made OAuth 2.0 a weaker default than OAuth 1.0. Solidus designed none of this.

Solidus today

auth.solidus.network issues Bearer Tokens as its default access-token type, for the plain OAuth 2.0 path, that's what /token returns, and resource servers check them exactly as RFC 6750 specifies (missing or invalid → 401 invalid_token, as the live proof above shows). The DPoP-bound alternative (see that entry) only activates for the specific Solid-OIDC flow requesting a webid scope, most other Solidus client integrations still receive ordinary bearer tokens today. Everything runs on Solidus's public testnet, unaudited.

See also

OAuth 2.0 is the framework this token type belongs to. DPoP is the sender-constrained upgrade over a plain bearer token. Token Introspection is how a resource server checks whether one is still valid.