OAuth 2.0 Bearer Token Usage (RFC 6750) describes how to use Bearer Tokens in HTTP requests to access OAuth 2.0 Protected Resources. Any party in possession of a Bearer Tokens (a "bearer") can use it to get access to the associated Protected Resources (without demonstrating possession of a cryptographic Key). To prevent misuse, Bearer Tokens need to be protected from disclosure in storage and in transport.

Summary of Recommendations#

Safeguard Bearer Tokens#

Client implementations MUST ensure that Bearer Tokens are not leaked to unintended parties, as they will be able to use them to gain access to protected resources. This is the primary security consideration when using Bearer Tokens and underlies all the more specific recommendations that follow.

Validate TLS certificate chains#

The client MUST validate the TLS Certificate Chain when making requests to Protected Resources.

Failing to do so may enable DNS hijacking attacks to steal the Bearer Tokens and gain unintended access.

Always use TLS (HTTPS)#

Clients MUST always use TLS RFC 5246 (https) or equivalent transport security when making requests with Bearer Tokens. Failing to do so exposes the token to numerous attacks that could give attackers unintended access.

Don't store bearer tokens in Cookie#

Implementations MUST NOT store Bearer Tokens within Cookie that can be sent in the clear (which is the default transmission mode for Cookie). Implementations that do store Bearer Tokens in cookies MUST take precautions against cross-site request forgery.

Issue short-lived bearer tokens#

Token servers SHOULD issue short-lived (one hour or less) Bearer Tokens, particularly when issuing tokens to clients that run within a web browser or other environments where information leakage may occur. Using short-lived Bearer Tokens can reduce the impact of them being leaked.

Issue scoped Bearer Tokens#

Token servers SHOULD issue Bearer Tokens that contain an audience restriction, scoping their use to the intended relying party or set of relying parties.

Don't pass Bearer Tokens in page URLs#

Bearer Tokens SHOULD NOT be passed in page URLs (for example, as query string parameters). Instead, bearer tokens SHOULD be passed in HTTP Header Fields or message bodies for which confidentiality measures are taken.

Browsers, web servers, and other software may not adequately secure URLs in the browser history, web server logs, and other data structures. If Bearer Tokens are passed in page URLs, attackers might be able to steal them from the history data, logs, or other unsecured locations.

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-6) was last changed on 01-Jul-2016 14:20 by jim