OAuth 2.0 Audience Information


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:

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].

Step (3)#

The 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.

More Information#

There might be more information for this subject on one of the following: