/oauth2/par

The /oauth2/par endpoint is the OAuth 2.0 pushed authorization request (PAR) endpoint defined in RFC 9126.

Use this endpoint to push an authorization request payload directly to the authorization server for the following flows:

Authorization code grant (OAuth 2.0 and OIDC)
Authorization code grant with PKCE (OAuth 2.0 and OIDC)
Implicit grant (OAuth 2.0 and OIDC)

Specify the realm in the request URL; for example:

https://am.example.com:8443/am/oauth2/realms/root/realms/alpha/par

The PAR endpoint supports the following parameters:

Parameter Description Required

Parameter	Description	Required
`acr_values`	The OpenID Connect authentication context class reference values.	Yes, if required by the OpenID Connect provider
`authorization_details`	Additional fine-grained authorization requirements, as specified in RFC 9396: OAuth 2.0 Rich Authorization Requests.	No. Accepted only if remote consent is configured.
`claims`	The user attributes to be returned in the ID token.	No
`client_assertion`	A signed JSON Web Token (JWT) to use as client credentials.	Yes, for JWT profile authentication
`client_assertion_type`	The type of assertion, `client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer`.	Yes, for JWT profile authentication
`client_id`	Uniquely identifies the application making the request.	Yes, even when it is also included in a `request` object
`client_secret`	The password for a confidential client.	Yes, when authenticating with Form parameters (HTTP POST)
`code_challenge`	The code verifier generated for the PKCE flow.	Yes, for confidential clients and for all clients using the Authorization code grant with PKCE flow
`code_challenge_method`	The method to derive the code challenge.	Yes, when the `code_challenge` is hashed (recommended)
`csrf`	The SSO token string linking the request to the user session to protect against Cross-Site Request Forgery attacks.	Yes, when gathering consent without a remote consent service
`decision`	Specifies whether the resource owner consents to the requested access.	Yes, when gathering consent unless consent is already saved for the scope
`id_token_hint`	Previously issued ID token previously passed as a hint about the end user’s session with the client.	No
`login_hint`	String value that can be set to the ID the user uses to log in.	No
`nonce`	String value that associates the client session with the ID token.	No
`prompt`	Specifies whether to prompt the end user for authentication and consent.	No
`redirect_uri`	The URI to return the resource owner to after authorization is complete. The value must match a redirect URI pre-registered for the client. AM doesn’t currently support per-request unregistered redirect URIs.	No
`request`	A signed and encrypted JWT that contains the request parameters used for JWT-Secured Authorization Requests (JAR). When using JAR, the request JWT must be signed with the client’s private key and encrypted with the authorization server’s public key. You can obtain the authorization server’s public key from its JWKS URI. All request parameters must be included as claims inside the JWT. Only the following client authentication parameters can be used alongside the `request` parameter: `client_assertion` `client_assertion_type` `client_id` `client_secret` Otherwise, the response is an `Invalid parameter scope` error.	Yes
`response_mode`	Specifies the mechanism for returning response parameters.	No
`response_type`	The type of response expected from the authorization server.	Yes
`save_consent`	Specifies whether to store a resource owner’s consented scopes.	No
`scope`	The scopes linked to the permissions requested by the client from the resource owner.	No
`service`	The authentication journey to use when authenticating the resource owner.	No
`state`	The value to maintain state between the request and the callback.	No, but strongly recommended
`ui_locales`	The end user’s preferred languages for the user interface.	No

acr_values

The OpenID Connect authentication context class reference values.

Yes, if required by the OpenID Connect provider

authorization_details

Additional fine-grained authorization requirements, as specified in RFC 9396: OAuth 2.0 Rich Authorization Requests.

No. Accepted only if remote consent is configured.

claims

The user attributes to be returned in the ID token.

client_assertion

A signed JSON Web Token (JWT) to use as client credentials.

Yes, for JWT profile authentication

client_assertion_type

The type of assertion, client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer.

Yes, for JWT profile authentication

client_id

Uniquely identifies the application making the request.

Yes, even when it is also included in a request object

client_secret

The password for a confidential client.

Yes, when authenticating with Form parameters (HTTP POST)

code_challenge

The code verifier generated for the PKCE flow.

Yes, for confidential clients and for all clients using the Authorization code grant with PKCE flow

code_challenge_method

The method to derive the code challenge.

Yes, when the code_challenge is hashed (recommended)

csrf

The SSO token string linking the request to the user session to protect against Cross-Site Request Forgery attacks.

Yes, when gathering consent without a remote consent service

decision

Specifies whether the resource owner consents to the requested access.

Yes, when gathering consent unless consent is already saved for the scope

id_token_hint

Previously issued ID token previously passed as a hint about the end user’s session with the client.

login_hint

String value that can be set to the ID the user uses to log in.

nonce

String value that associates the client session with the ID token.

prompt

Specifies whether to prompt the end user for authentication and consent.

redirect_uri

The URI to return the resource owner to after authorization is complete.

The value must match a redirect URI pre-registered for the client. AM doesn’t currently support per-request unregistered redirect URIs.

request

A signed and encrypted JWT that contains the request parameters used for JWT-Secured Authorization Requests (JAR).

When using JAR, the request JWT must be signed with the client’s private key and encrypted with the authorization server’s public key. You can obtain the authorization server’s public key from its JWKS URI.

All request parameters must be included as claims inside the JWT. Only the following client authentication parameters can be used alongside the request parameter: