!!! Overview
[{$pagename}] which as far as we know is only defined within [draft-tschofenig-oauth-audience-00.txt|https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00|target='_blank'] 

The [OAuth 2.0] [Bearer Token] specification allows any party in possession of a [Bearer Token] to get access to the associated resources (without demonstrating possession of a cryptographic key).

To prevent misuse, two important security assumptions must hold:
* [Bearer Tokens] [MUST] be protected from disclosure in [data At Rest] and in [data In Transit] 
* the [Access Token] must only be valid for use with a specific [Resource Server] (the audience) and with a specific [OAuth Scope].

[{$pagename}] document defines a new header that is used by the [OAuth Client] to indicate what [Resource Server], as the intended recipient, it wants to access.  This information is subsequently also communicated by the [Authorization Server] securely to the [Resource Server], for example  within the audience field of the [Access Token].

! Step (0)
As an initial step the [client|OAuth Client] typically determines the resource server it wants to interact with, for example, as part of a [discovery|Discovery Mechanism] procedure.

! Step (1)
The [client|OAuth Client] starts the [OAuth 2.0] protocol interaction based on the selected [Grant Type].

! Step (2)
When the [client|OAuth Client] interacts with the token endpoint to obtain an [Access Token] it MUST populate the newly defined 'audience' parameter with the information obtained in step (0).

The [Resource Server] who obtains the request needs to parse it to determine whether the provided audience value matches any of the authorized [Resource Servers] it has a relationship with. If the [Authorization Server] fails to parse the provided value it __MUST__ reject the request using an error response with the error code "invalid_request".  If the [Authorization Server] does not consider the [Resource Server] acceptable then it __MUST__ return an error response with the error code "access_denied".  In both cases additional error information may be provided via the error_description, and the error_uri parameters.  If the request has, however, been verified successfully then the [Authorization Server] __MUST__ include the audience claim into the [Access Token] with the value copied from the audience field provided by the [client|OAuth Client]. In case the [Access Token] is encoded using the [JSON Web Token] format [6] the "aud" claim __MUST__ be used.  The [Access Token] __MUST__ be protected against modification by protecting it with either a [Digital Signature] or a keyed message digest.  The [Authorization Server] returns the [Access Token] to the client, as specified in [4].

! Step (3)
The [client|OAuth Client] follows the OAuth 2.0 specification [4] and the specification relevant for the selected token type (e.g., the bearer token specification) to interact with the [Resource Server] to make a request to the protected resource with the attached [Access Token].

! Step (4)
When the [Resource Server] receives the [Access Token] it  verifies it according to chosen [Access Token] encoding.  For example, in case the [JSON Web Token] format is used then it must adhere to the guidance in [6].  In any case, the [Resource Server] __MUST__ verify whether the URI contained in the "aud" claim matches it's own.  If the comparison fails the [Resource Server] __MUST__ return an error to the [client|OAuth Client].


!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]