!!! Overview
[{$pagename}] ([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|Data At Rest] and in [transport|Data In Transit].


!! 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|Certificate Validation] 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|HTTP Header Field] 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:
[{ReferringPagesPlugin before='*' after='\n' }]