use more than one method to transmit the token in one request.

Condition: when sending bearer access tokens in resource requests

Clients MUST NOT use more than one method to transmit the token in each request.

use form-body token transmission unless the content type is application/x-www-form-urlencoded, its encoding rules are followed, the body is single-part and ASCII-only, and the method has defined request-body semantics.

Condition: when placing an access token in the HTTP request entity-body

The client MUST NOT use this method unless all of the following conditions are met:

use the GET method.

Condition: when using form-body token transmission

the "GET" method MUST NOT be used.

ensure content encoded in the entity-body consists entirely of ASCII characters.

Condition: when using form-body token transmission

The content to be encoded in the entity-body MUST consist entirely of ASCII characters.

separate the access_token parameter from other request-specific body parameters using ampersand characters.

Condition: when the entity-body includes other request-specific parameters

the "access_token" parameter MUST be properly separated from the request-specific parameters using "&" character(s)

separate the access_token parameter from other request-specific query parameters using ampersand characters.

Condition: when the URI query includes other request-specific parameters

the "access_token" parameter MUST be properly separated from the request-specific parameters using "&" character(s)

validate the TLS certificate chain, including checking the certificate revocation list.

Condition: when requesting protected resources

the client MUST validate the TLS certificate chain when making requests to protected resources, including checking the Certificate Revocation List

verify the identity of the resource server.

Condition: when presenting a bearer token

the client MUST verify the identity of that resource server

prevent bearer tokens from leaking to unintended parties.

Client implementations MUST ensure that bearer tokens are not leaked to unintended parties

use form-body token transmission except where participating browsers cannot access the Authorization request header field.

The "application/x-www-form-urlencoded" method SHOULD NOT be used except in application contexts where participating browsers do not have access to the "Authorization" request header field.

use URI-query token transmission unless header and entity-body transmission are impossible.

it SHOULD NOT be used unless it is impossible to transport the access token in the "Authorization" request header field or the HTTP request entity-body.

use the Authorization request header field with the Bearer HTTP authorization scheme.

Condition: when making authenticated requests with a bearer token

Clients SHOULD make authenticated requests with a bearer token using the "Authorization" request header field

send a Cache-Control header containing the no-store option.

Condition: when using URI-query token transmission

Clients using the URI Query Parameter method SHOULD also send a Cache-Control header containing the "no-store" option.

request a new access token and retry the protected-resource request.

Condition: after an invalid_token error

The client MAY request a new access token and retry the protected resource request.

implement TLS.

The authorization server MUST implement TLS.

restrict token use to a specific scope.

Condition: to mitigate token redirect

Restricting the use of the token to a specific scope is also RECOMMENDED.

include the realm attribute more than once.

Condition: in a Bearer challenge

The "realm" attribute MUST NOT appear more than once.

include the scope attribute more than once.

Condition: in a Bearer challenge

The "scope" attribute MUST NOT appear more than once.

include error, error_description, or error_uri more than once each.

Condition: in a Bearer challenge

The "error", "error_description", and "error_uri" attributes MUST NOT appear more than once.

use characters outside the permitted scope-value and delimiter character sets.

Condition: in a Bearer challenge scope attribute

Values for the "scope" attribute MUST NOT include characters outside the set %x21 / %x23-5B / %x5D-7E for representing scope values and %x20 for delimiters

use characters outside %x20-21, %x23-5B, and %x5D-7E.

Condition: in error and error_description attributes

Values for the "error" and "error_description" attributes MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E.

support bearer-token transmission through the Authorization request header field.

Resource servers MUST support this method.

include the WWW-Authenticate response header field.

Condition: when a protected-resource request lacks authentication credentials or an access token enabling access

the resource server MUST include the HTTP "WWW-Authenticate" response header field

make error_uri values conform to URI-reference syntax.

Condition: when including error_uri in a Bearer challenge

Values for the "error_uri" attribute MUST conform to the URI-reference syntax

include an error code or other error information.

Condition: when the request lacks all authentication information

the resource server SHOULD NOT include an error code or other error information.

include a Cache-Control header containing the private option in successful responses.

Condition: when responding successfully to URI-query token requests

Server success (2XX status) responses to these requests SHOULD contain a Cache-Control header with the "private" option.

include the error attribute explaining why access was declined.

Condition: when a request included an access token but authentication failed

the resource server SHOULD include the "error" attribute

respond with HTTP 400 Bad Request.

Condition: for an invalid_request error

The resource server SHOULD respond with the HTTP 400 (Bad Request) status code.

respond with HTTP 401 Unauthorized.

Condition: for an invalid_token error

The resource SHOULD respond with the HTTP 401 (Unauthorized) status code.

respond with HTTP 403 Forbidden.

Condition: for an insufficient_scope error

The resource server SHOULD respond with the HTTP 403 (Forbidden) status code

use mechanisms for sender-constraining access tokens.

Condition: to prevent misuse of stolen or leaked access tokens

Authorization and resource servers SHOULD use mechanisms for sender-constraining access tokens

support form-body bearer-token transmission.

Resource servers MAY support this method.

support URI-query bearer-token transmission.

Resource servers MAY support this method.

include the WWW-Authenticate response header field.

Condition: in response to other conditions

it MAY include it in response to other conditions as well.

include the scope attribute identifying the scope needed for access.

Condition: for an insufficient_scope error

MAY include the "scope" attribute with the scope necessary to access the protected resource.

issue bearer tokens with lifetimes of one hour or less.

Condition: particularly for browser clients or environments where information leakage may occur

Token servers SHOULD issue short-lived (one hour or less) bearer tokens

issue bearer tokens containing an audience restriction.

Condition: to restrict use to the intended relying party or parties

Token servers SHOULD issue bearer tokens that contain an audience restriction

use the Bearer auth-scheme value.

All challenges defined by this specification MUST use the auth-scheme value "Bearer".

be followed by one or more auth-param values.

This scheme MUST be followed by one or more auth-param values.

store bearer tokens in cookies that can be sent in the clear.

bearer tokens MUST NOT be stored in cookies that can be sent in the clear.

apply TLS confidentiality and integrity protection to client-to-authorization-server and client-to-resource-server communication.

Condition: to protect against token disclosure

confidentiality protection MUST be applied using TLS with a ciphersuite that provides confidentiality and integrity protection.

encrypt the token in addition to using TLS.

Condition: when the client is prevented from observing the token contents

token encryption MUST be applied in addition to the usage of TLS protection.

apply confidentiality protection to exchanges between clients and authorization servers and between clients and resource servers.

Condition: to mitigate token capture and replay

confidentiality protection of the exchanges between the client and the authorization server and between the client and the resource server MUST be applied.

take precautions against cross-site request forgery.

Condition: when storing bearer tokens in cookies

Implementations that do store bearer tokens in cookies MUST take precautions against cross-site request forgery.

provide integrity protection sufficient to prevent token modification.

The token integrity protection MUST be sufficient to prevent the token from being modified.

make reference token values infeasible for attackers to guess.

Condition: when a bearer token contains a reference to authorization information

Such references MUST be infeasible for an attacker to guess

pass bearer tokens in page URLs.

Bearer tokens SHOULD NOT be passed in page URLs

pass bearer tokens in HTTP message headers or confidentiality-protected message bodies.

Condition: instead of page URLs

bearer tokens SHOULD be passed in HTTP message headers or message bodies for which confidentiality measures are taken.

protect token confidentiality between front-end and back-end servers.

Condition: when TLS terminates before the server providing the resource

sufficient measures MUST be employed to ensure confidentiality of the token between the front-end and back-end servers

limit token lifetime.

Condition: to mitigate token capture and replay

the lifetime of the token MUST be limited