Skip to main content

par

Implementing the Pushed Authorization Request (PAR) Flow

Pushed Authorization Request (PAR) is an OAuth 2.0 extension (RFC 9126) that allows clients to push authorization request parameters to the authorization server via a direct request, rather than including them in the authorization URL. This improves security by avoiding long URLs, reducing exposure of sensitive parameters, and enabling better logging and audit trails.

PAR is recommended for enhanced security, especially when dealing with complex authorization requests or when you want to avoid exposing authorization parameters in URLs. It works seamlessly with both Authorization Code Flow and PKCE Flow.

How it works?

Before we step into the mechanics of working lets us understand some useful parameters.

Parameter NameDescription
client_idclient which represents the business-App in cidaas, where the Resource Owner wants to have access
redirect_uriURI where cidaas should redirect to, after login
response_typetype of response. Typically code for Authorization Code Flow or PKCE Flow
scopescope which the user asks for. E.g. openid profile email gives access to user profile and email data
staterandom onetime string which will be generated at the beginning of the flow. Recommended to avoid CSRF
code_challengeBASE64-URL-encoded string of the hash of the code_verifier. Required for PKCE flow
code_challenge_methodMethod which was used for hashing code_challenge. Recommended is S256
request_uriThe URI returned by the PAR endpoint that can be used in place of authorization request parameters
expires_inLifetime in seconds of the request URI. The request URI must be used within this time period

Let's take up the scenario of a user who wants to get access to the business app using PAR.

Step 1: The client application pushes the authorization request parameters to the PAR endpoint (/authz-srv/par) via a POST request. This includes all the standard OAuth 2.0 authorization parameters like client_id, redirect_uri, response_type, scope, state, and optionally code_challenge and code_challenge_method for PKCE.

Step 2: cidaas validates the request and creates a unique request_uri that represents the pushed authorization request. The system returns the request_uri along with an expires_in value indicating how long the URI is valid.

Step 3: The client application uses the request_uri in place of the authorization request parameters when redirecting to the authorization endpoint. Instead of a long URL with all parameters, the client redirects to /authz-srv/authz?client_id=xxx&request_uri=urn:ietf:params:oauth:request_uri:abc123.

Step 4: cidaas retrieves the authorization request parameters associated with the request_uri and processes the authorization request as normal. The endpoint will verify if the user is already logged in (SSO) and if not will redirect the user to the login page.

Step 5: The user will then enter their credentials on the login page and click on submit.

Step 6: After successful authentication cidaas will return a code to the provided redirect_uri in the original PAR request. The client must verify whether the state returned by the authorization server (cidaas) is equal to the state passed in Step 1.

Step 7: The Client then requests Access Token from Authorization Server. Thereby, he passes the one-time-use code as code to the backend, as well as grant_type=authorization_code (and code_verifier if using PKCE).

Step 8: The Resource Server validates the Access Token and uses it to serve the requests or retrieve additional details from the /users-srv/userinfo Endpoint.

Note

PAR can be used with both Authorization Code Flow and PKCE Flow. The request_uri expires after the time specified in expires_in (typically 90 seconds), so it must be used promptly. After expiration, a new PAR request must be made.

Technical integration

APIDescriptionLink to API
Push Authorization RequestThis call pushes authorization request parameters and returns a request_uriLink to API
Start Authorization with request_uriTo perform an authorization request using the request_uri from PARLink to API
Exchange CodeTo exchange the code for a tokenLink to API

Example Request

Push Authorization Request:

curl --location '{{domain}}/authz-srv/par' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic OTVkZWFmYzktYjE2OS00YWI0LWEzMzYtNDI2YWEyOTEwM2UxOlBEUXFWakQyNTEzZ1hzeWh4VjdTdkRMcUlXMG5oeW5Wd0RvcE1lemN0Ym55Tw==' \
--data-urlencode 'client_id=your_client_id' \
--data-urlencode 'redirect_uri=https://example.com/callback' \
--data-urlencode 'response_type=code' \
--data-urlencode 'scope=openid profile email' \
--data-urlencode 'state=QBTVJ59VHOTKRKUCQ18V' \
--data-urlencode 'code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM' \
--data-urlencode 'code_challenge_method=S256' \
--data-urlencode 'response_mode=query'

Response:

{
"request_uri": "urn:ietf:params:oauth:request_uri:abc123def456",
"expires_in": 90
}

Authorization Request with request_uri:

curl --location '{{domain}}/authz-srv/authz?client_id=your_client_id&request_uri=urn:ietf:params:oauth:request_uri:abc123def456'

Need Support?

Please contact us directly on our support page