This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 1 added 32 lines
!!! 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' }]