Overview#OAuth 2.0 Audience Information which as far as we know is only defined within draft-tschofenig-oauth-audience-00.txt
To prevent misuse, two important security assumptions must hold:
- Bearer Tokens must be protected from disclosure in storage and in transport
- the Access Token must only be valid for use with a specific Resource Server (the audience) and with a specific OAuth Scope.
OAuth 2.0 Audience Information document defines a new header that is used by the 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 typically determines the resource server it wants to interact with, for example, as part of a discovery procedure.
Step (1)#The client starts the OAuth 2.0 protocol interaction based on the selected Grant Type.
Step (2)#When the 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. In case the Access Token is encoded using the JSON Web Token format  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 .