Overview#
OAuth 2.0 Audience Information which as far as we know is only defined within draft-tschofenig-oauth-audience-00.txt
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.
OAuth 2.0 Audience Information 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 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 [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].
