Pushed Authorization Request (PAR)

PAR (RFC 9126) sends authorization parameters to cidaas in a back-channel POST first. The browser then opens /authz-srv/authz with only client_id and a short-lived request_uri — scopes, PKCE, and hints never sit in a long authorize URL.

See Standards & Security Extensions for when to choose PAR versus other request-integrity options (for example JAR).

PAR works with Authorization Code and PKCE. Use it when authorize URLs would otherwise get long, or when you want a clearer audit trail of what was requested.

Application configuration

Configure allowed_web_origins on the OAuth2 / OIDC application in Integrations → Applications (Trustdesk) or via the App Configuration API. See App management.

cidaas checks this origin during PAR and standard authorization. A mismatch happens when the page that starts login (POST /authz-srv/par or redirect to /authz-srv/authz) is not listed. The request is then rejected.

Setting	Purpose	Example
redirect_uris	Where cidaas may redirect after login	https://app.example.com/callback
allowed_web_origins	Which origins may start login from the browser	https://app.example.com

Both must be set. A valid redirect_uri alone does not satisfy the origin check — add the origin of the page that triggers PAR, without the path.

Missing origin → AUTH10043 (invalid_request) on POST /authz-srv/par (HTTP 403). See the PAR API.

How it works

Parameters

Parameter	Description
client_id	Application in cidaas
redirect_uri	Callback after login
response_type	Typically code
scope	For example openid profile email
state	One-time CSRF value
code_challenge	BASE64URL hash of code_verifier (PKCE)
code_challenge_method	Prefer S256
request_uri	Reference returned by PAR
expires_in	Lifetime of request_uri in seconds

Steps

1. Push — POST all authorize parameters to /authz-srv/par (including PKCE fields when used). Confidential clients authenticate at PAR; public clients send client_id plus PKCE.
2. Reference — cidaas returns request_uri and expires_in (typically 90 seconds). Use it promptly; after expiry, push again.
3. Authorize — Redirect the browser to /authz-srv/authz?client_id=…&request_uri=….
4. Authenticate — SSO or hosted login, same as a normal code flow.
5. Callback — cidaas returns code (and state) to redirect_uri. Compare state with step 1.
6. Token — POST /token-srv/token with grant_type=authorization_code, code, and code_verifier for PKCE.
7. Resource — Call your API with the access token, or /users-srv/userinfo.

Technical integration

API	Description	Link
Pushed Authorization Request	Push parameters, receive request_uri	PAR API
Start authorization	Browser request with request_uri	Authorize API
Exchange code	Code for tokens	Token API

Example: push

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
}

Example: authorize 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?

Contact us on our support page or at [email protected].