Skip to content

Authorization Details

The BankID OIDC Provider supports the authorization_details parameter as defined in the OAuth 2.0 Rich Authorization Requests (RAR) specification. This parameter allows including permission statements directly in PAR requests, eliminating the need for a separate Permissions API request.

Note

The authorization_details parameter is only accepted in PAR requests.

Request Format

The value is a URL-encoded JSON array containing a single permission item.

[{
    "type": "payment.v1",
    "permission": "<base64url-encoded permission statement>"
}]

Fields

Field Type Required Description
type string Yes The permission type. See the Permissions API for supported types.
permission string Yes Base64url-encoded permission statement (e.g. payment details, text to approve). See permission statement.

All optional fields from the Permissions API are also supported. Refer to the Permissions API definition for the complete list of available fields.

Token Response

When authorization_details is included in the request, the token response will include authorization_details as a top-level field, and the resulting tokens will contain additional claims:

Token Response Body

The token response includes authorization_details as a top-level field alongside access_token, id_token, etc.

{
  ...
  "authorization_details": [{
    "type": "payment.v1",
    "permission": "eyJub25jZSI6Imk...",
    "permission_digest": "x4Fz5C9hQq0m3LXKBA72WL8jKRXsQ6TnGiven3Gcz0k="
  }]
}

ID Token

The ID token will include a permission_digest claim, a SHA-256 hash of the permission statement. This can be used to verify the integrity of the permission statement.

{
  ...
  "permission_digest": "x4Fz5C9hQq0m3LXKBA72WL8jKRXsQ6TnGiven3Gcz0k="
}

Access Token

The access token will include the authorization_details claim with the original request fields plus the permission_digest.

{
  ...
  "authorization_details": [{
    "type": "payment.v1",
    "permission": "eyJub25jZSI6Imk...",
    "permission_digest": "x4Fz5C9hQq0m3LXKBA72WL8jKRXsQ6TnGiven3Gcz0k="
  }]
}

Example

POST [pushed_authorization_request_endpoint]
Content-Type: application/x-www-form-urlencoded

client_id=myclient-bankid-current
&scope=openid+profile
&redirect_uri=https%3A%2F%2Fmywebapp.example.org%2Fcallback
&response_type=code
&state=01e3ac8e-4a26-4dfb-79ca-2631394c4144
&nonce=1fb72f68-1bea-2ba2-12d7-24df1c999d1b
&code_challenge=rMU4NcLC3_O_tsTZ3gQE1ONoXD6OMZph_2zRuobajhQ
&code_challenge_method=S256
&authorization_details=%5B%7B%22type%22%3A%20%22payment.v1%22%2C%20%22permission%22%3A%22eyJub25jZSI6ImRXNXBjWFZsSUhaaGJIVmwiLCJpZCI6IlltRnphMlYwSUdsayIsInBheW1lbnRzIjpbeyJwYXltZW50SWQiOiJjR0Y1YldWdWRDQnBaQSIsImFtb3VudCI6IjEyMy40NSIsImN1cnJlbmN5IjoiTk9LIiwiY3JlZGl0b3JOYW1lIjoiU2Nyb29nZSBNY0R1Y2sifV19%22%7D%5D

Error Responses

HTTP Status Error Code Description
400 invalid_request Invalid JSON structure, multi-item array, or invalid Base64url encoding in permission field.
403 unauthorized_client Client does not have the required scopes for the requested permission type.

Size Limits

10,000 character limit

The authorization_details parameter is subject to a 10,000 character limit. Requests exceeding this limit will be silently dropped: the authorization flow will proceed, but the authorization_details claim will not appear in the resulting tokens. If your permission statements require more than 10,000 characters, use the Permissions API instead.

Large authorization_details leads to large access tokens

The authorization_details value (including the full base64url-encoded permission statement) is embedded in the access token as a claim. This means the access token size grows proportionally with the permission payload.

Large access tokens are typically sent in the HTTP Authorization header. Many infrastructure components (reverse proxies, load balancers, application servers, CDNs) enforce default header size limits, commonly 8 KB. An access token exceeding these limits will cause downstream API calls to fail with HTTP 400, HTTP 502, or connection-level errors depending on the component enforcing the limit.