1. Pushed Authorization Request (PAR) Endpoint
The Pushed Authorization Request (PAR) flow is a mandatory extension of the OIDC authorization code flow for FAPI 2.0, as defined in RFC 9126.
It allows the Relying Party (RP) to register sensitive authorization request parameters directly with Corppass via a secure back-channel POST request. By "pushing" these parameters directly to the server instead of encoding them in the browser URL, this significantly reduces the risk of leaking sensitive data (e.g., scope, redirect_uri) and ensures integrity by authenticating the request before the user interaction begins.
Request
To initiate the flow, send a POST request to the PAR Endpoint URL obtained from the OpenID Discovery Endpoint (pushed_authorization_request_endpoint).
POST /requestRequest Headers
Content-Type
Yes
Indicates the encoding format of the request body.
Must be set to application/x-www-form-urlencoded.
DPoP
Yes
The JWK Thumbprint of your proof-of-possession public key. The JWK thumbprint should be computed using the SHA256 hash algorithm, and encoded using base64url.
Optional if you provide the DPoP Proof JWK in the dpop_jkt request parameter (see Request Body section below). If both are provided, they must match.
For simplicity, we recommend sending the DPoP header over the use of dpop_jkt request parameter, as the DPoP header is mandatory for later steps.
Refer to the Demonstrating Proof of Possession section for more details.
Request Body
client_id
Yes
The client identifier assigned to the RP during onboarding.
client_assertion
Yes
A JWT identifying the client.
Refer to Client Assertion JWT section for more details.
client_assertion_type
Yes
The type of client assertion.
Must be set to urn:ietf:params:oauth:client-assertion-type:jwt-bearer, as mandated by OIDC specifications.
code_challenge
Yes
The encoded, hashed value of the client-generated code_verifier.
Refer to Proof Key of Code Exchange for more details.
code_challenge_method
Yes
The method used to generate the code_challenge from the code_verifier.
Must be set to S256, as mandated by FAPI 2.0 specifications.
response_type
Yes
The authorization processing flow to use.
Must be set to code, as mandated by FAPI 2.0 specifications.
redirect_uri
Yes
The callback URL where Corppass will redirect the user upon authorisation. The value must match one of the redirect URLs that were pre-registered during onboarding.
scope
Yes
Space-delimited list of requested scopes.
Each scope grants access to a set of entity or acting user's attributes called claims. Once authorised, these claims are returned in an ID Token (via the Token Endpoint) and/or made available via the Userinfo Endpoint.
Must include openid scope. Unrecognised or unauthorised scopes will result in an error.
Refer to the Scopes section for more details.
state
Yes
A client-provided value used to maintain state between the request and the callback. It helps mitigate Cross-Site Request Forgery (CSRF, XSRF) attacks.
This value should be unique, non-guessable, and generated for each authorization session.
The value is returned in the authorization response. The RP must validate that the returned state matches the value originally provided.
nonce
Yes
A client-provided value used to mitigate replay attacks.
This value should be unique, non-guessable, and generated for each authorization session.
The value is returned in the ID Token. The RP must validate that the returned nonce matches the value originally provided.
acr_values
No
Optional. A space-delimited string indicating desired level of assurance (LoA) for the authentication.
If multiple values are provided, they should be listed in descending order of preference. The authorization server will use the first supported / available value.
If not provided, Corppass defaults to the client's configured level.
Supported values:
urn:singpass:authentication:loa:2This refers to an assurance level of 2, meaning that only 2FA is required.
More value types may be introduced in the future.
authentication_context_type
Yes
A value from a predefined list describing the type of transaction for which your user is performing the authentication. This is used for anti-fraud purposes. Refer to the Authentication Context Parameters section for more details.
authentication_context_message
No
Optional. A string value providing context on what users are performing authentication for. This will be displayed to users during authentication.
dpop_jkt
No
The JWK Thumbprint of your proof-of-possession public key. The JWK thumbprint should be computed using the SHA256 hash algorithm, and encoded using base64url.
Optional if DPoP header is provided. If both are provided, they must match.
For simplicity, we recommend sending the DPoP header over the use of dpop_jkt request parameter, as the DPoP header is mandatory for later steps.
Refer to the Demonstrating Proof of Possession section for more details.
Sample Request
Success Response
If the request is valid, Corppass registers the provided parameters and returns a JSON response containing a request_uri.
Response Body
request_uri
String
A reference to the authorization payload.
Use this in the subsequent redirect to the Authorization Endpoint.
expires_in
Number
The lifetime of the request_uri in seconds.
This is set to 60 seconds.
Sample Response
Error Response
If the request is malformed, unauthorised, or contains invalid parameters, Corppass returns a JSON response containing an error code and description.
Response Body
error_description
String
A human-readable description of the error.
state
String
The same state parameter value provided by the client in the pushed authorization request, returned as-is.
Error Codes
invalid_request
400
The request is missing a required parameter, includes an unsupported value, or is malformed.
invalid_client
400 / 401
Client authentication failed due to a missing, invalid, expired, or improperly formatted client credential or assertion.
invalid_scope
400
The requested scope is invalid, unknown, malformed, or exceeds the scope granted to the client.
invalid_dpop_proof
401
The DPoP proof is invalid, expired, malformed, or failed verification.
server_error
500
The authorization server encountered an unexpected internal error while processing the request.
temporarily_unavailable
503
The server is temporarily unable to handle the request due to maintenance or high load.
Sample Response
Next Steps
Redirect the User: Upon successful retrieval of the request_uri from the PAR response, the next step is to redirect the user's browser to the Authorization Endpoint.
The request_uri serves as a secure reference to the parameters registered in this step and is used to construct the redirect URL, replacing the full list of query parameters typically used in legacy flows.
Proceed to 2. Authorization Endpoint to redirect the user and obtain the Authorization Code.
Last updated