Skip to main content

3. Authorization Request

The authorization_details authorization request parameter can be used to specify authorization requirements in all places where the scope parameter is used for the same purpose, examples include:

  • authorization requests as specified in [RFC6749]
  • device authorization requests as specified in [RFC8628]
  • backchannel authentication requests as defined in [OID-CIBA]

In case of authorization requests as defined in [RFC6749], implementers MAY consider using pushed authorization requests [RFC9126] to improve the security, privacy, and reliability of the flow. See Sections 12, 13, and 11.4 for details.

Parameter encoding is determined by the respective context. In the context of an authorization request according to [RFC6749], the parameter is encoded using the application/x-www-form-urlencoded format of the serialized JSON as shown in Figure 8, using the example from Section 2 (line breaks for display purposes only):

GET /authorize?response_type=code
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&code_challenge_method=S256
&code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bwc-uCHaoeK1t8U
&authorization_details=%5B%7B%22type%22%3A%22account%5Finformation%22%2C%22actions%22%3A%5B%22list%5Faccounts%22%2C%22read%5Fbalances%22%2C%22read%5Ftransactions%22%5D%2C%22locations%22%3A%5B%22https%3A%2F%2Fexample%2Ecom%2Faccounts%22%5D%7D%2C%7B%22type%22%3A%22payment%5Finitiation%22%2C%22actions%22%3A%5B%22initiate%22%2C%22status%22%2C%22cancel%22%5D%2C%22locations%22%3A%5B%22https%3A%2F%2Fexample%2Ecom%2Fpayments%22%5D%2C%22instructedAmount%22%3A%7B%22currency%22%3A%22EUR%22%2C%22amount%22%3A%22123%2E50%22%7D%2C%22creditorName%22%3A%22Merchant%20A%22%2C%22creditorAccount%22%3A%7B%22iban%22%3A%22DE02100100109307118603%22%7D%2C%22remittanceInformationUnstructured%22%3A%22Ref%20Number%20Merchant%22%7D%5D HTTP/1.1
Host: server.example.com

Based on the data provided in the authorization_details parameter, the AS will ask the user for consent to the requested access permissions.

Note: The user may also grant a subset of the requested authorization details.

3.1. Relationship to the "scope" Parameter​

authorization_details and scope can be used in the same authorization request for carrying independent authorization requirements. Combined use of authorization_details and scope is supported by this specification in part to allow existing OAuth-based applications to incrementally migrate towards using authorization_details exclusively. It is RECOMMENDED that a given API use only one form of requirement specification.

The AS MUST process both sets of requirements in combination with each other for the given authorization request. The details of how the AS combines these parameters are specific to the APIs being protected and outside the scope of this specification.

When gathering user consent, the AS MUST present the merged set of requirements represented by the authorization request.

If the resource owner grants the client the requested access, the AS will issue tokens to the client that are associated with the respective authorization_details (and scope values, if applicable).

3.2. Relationship to the "resource" Parameter​

The resource authorization request parameter, as defined in [RFC8707], can be used to further determine the resources where the requested scope can be applied. The resource parameter does not have any impact on the way the AS processes the authorization_details authorization request parameter.

Last updated on