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.
Validation:
Must be set to
application/x-www-form-urlencoded.
DPoP
Yes
DPoP Proof JWT. A distinct JSON Web Token (JWT) that proves the client possesses the private key corresponding to the public key used for token binding.
Validation:
Optional only if the
dpop_jktparameter is provided in the request body.Mandatory if the
dpop_jktparameter is missing.If both are provided, the thumbprint derived from this header must match the
dpop_jktvalue.
Recommendation: We strongly recommend sending this Header rather than relying on the dpop_jkt parameter, as the DPoP header is mandatory for all subsequent token interactions.
Refer to the Demonstrating Proof of Possession section for more details.
Request Body
client_id
Yes
The unique identifier assigned to the Relying Party application during onboarding.
client_assertion
Yes
A signed JWT that identifies and authenticates the client application.
Validation:
Must be generated afresh for each authorization session.
Must contain a unique
jti(JWT ID) claim to prevent replay attacks.Must be signed using the Private Key corresponding to the public key registered in your JWKS.
Refer to Client Assertion JWT section for more details.
client_assertion_type
Yes
Specifies the format of the client assertion.
Validation:
Must be set to
urn:ietf:params:oauth:client-assertion-type:jwt-bearer, as mandated by OIDC specifications.
code_challenge
Yes
PKCE challenge. The base64url-encoded SHA-256 hash of the client-generated code_verifier.
Refer to Proof Key of Code Exchange for more details.
code_challenge_method
Yes
PKCE transformation method. The hashing method used to generate the code_challenge from the code_verifier.
Validation:
Must be set to
S256, as mandated by FAPI 2.0 specifications.
response_type
Yes
Indicates the authorization flow to be executed.
Validation:
Must be set to
code, as mandated by FAPI 2.0 specifications.
redirect_uri
Yes
The callback URL where the authorization server will redirect the user after successful authorization. Validation:
Must exactly match one of the Redirect URIs pre-registered during onboarding.
Partial matches or wildcard domains are not supported.
scope
Yes
A 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 the ID Token (via the Token Endpoint) and/or made available via the Userinfo Endpoint.
Validation:
Must include the
openidscope.Must only contain scopes authorized for your Client ID. Unrecognized scopes will result in an error.
Refer to the Scopes section for the full list of available values.
state
Yes
An opaque value used to maintain state between the request and callback. It serves as the primary defense against Cross-Site Request Forgery (CSRF) attacks.
Validation:
Must be unique, non-guessable, and cryptographically random.
Must be generated afresh for each authorization session.
The Relying Party must validate that the
statereturned in the authorization request callback matches the value originally sent.
nonce
Yes
A client-provided value used to mitigate replay attacks.
Validation:
Must be unique, non-guessable, and cryptographically random.
Must be generated afresh for each authorization session.
The Relying Party must verify that the
noncereturned in the ID Token strictly matches this value.
acr_values
No
Optional. A space-delimited string indicating desired level of assurance (LoA) for the authentication session.
If multiple values are provided, they should be listed in descending order of preference. The authorization server will attempt to satisfy the first available or supported value.
If omitted, the authorization server defaults to the client application's configured LoA.
Validation:
If provided, must correspond to a supported LoA.
Supported values:
urn:singpass:authentication:loa:2- LoA 2 (High): Requires 2-Factor Authentication (2FA).
Note: Additional LoA values may be introduced in the future to support different authentication standards.
authentication_context_type
Yes
A value from a predefined list describing the type of transaction for which the user is authenticating. This context is used by Corppass for risk assessment and anti-fraud monitoring.
Validation:
Must be one of the supported types configured for your specific client application.
Values not allow-listed for your client ID will be rejected.
Refer to the Authentication Context Parameters section for more details.
authentication_context_message
No
Optional. A string providing context on the purpose of the authentication request.
Validation:
Must contain only alphanumeric characters and spaces
Maximum length of 100 characters.
Note on usage: While currently optional, this value is slated for future enhancements where it will be displayed directly to the user during login. It is strongly advised to provide a clear, user-comprehensible message.
dpop_jkt
No
DPoP JWK Thumbprint. The base64url-encoded SHA-256 hash of your DPoP public key (JWK). This binds the authorization code to your specific key. Validation:
Optional if
DPoPheader is provided.Mandatory if the
DPoPheader is missing.If both are provided, the thumbprint derived from the
DPoPheader must match thedpop_jktvalue.
Recommendation: We recommend relying on the DPoP HTTP header rather than this parameter, as the header is mandatory for all subsequent token requests.
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 unique URI that references the stored authorization payload.
Use the exact value as the request_uri query parameter when redirecting the user to the Authorization Endpoint.
expires_in
Number
The lifetime of the request_uri in seconds.
This is set to 60 seconds. The client must initiate the redirect to the Authorization Endpoint within this time window, otherwise the request_uri will become invalid.
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
String
A standardised error code identifying the type of error that occurred.
See Error Codes below for a complete list of possible values.
error_description
String
A human-readable text description providing additional details about the error.
state
String
The opaque value originally provided by the client in the request body, returned unmodified.
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