> For the complete documentation index, see [llms.txt](https://docs.developer.singpass.gov.sg/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.developer.singpass.gov.sg/docs/singpass-developer-docs/corppass-and-myinfo-business/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/1.-pushed-authorization-request-par-endpoint.md). # 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](https://datatracker.ietf.org/doc/html/rfc9126). 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. #### Supported TLS Cipher Suites Please ensure you are using a supported cipher suite for this endpoint. Refer to [Supported TLS Cipher Suites](/docs/singpass-developer-docs/corppass-and-myinfo-business/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/supported-tls-cipher-suites.md) for the full list. ## Request To initiate the flow, send a `POST` request to the PAR Endpoint URL obtained from the [OpenID Discovery Endpoint](/docs/singpass-developer-docs/corppass-and-myinfo-business/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/0.-well-known-endpoints/openid-discovery-endpoint.md) (`pushed_authorization_request_endpoint`). ```http POST /request ``` ### Request Headers

Header Required Description

Header	Required	Description
`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_jkt` parameter is provided in the request body. Mandatory if the `dpop_jkt` parameter is missing. If both are provided, the thumbprint derived from this header must match the `dpop_jkt` value. 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.

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_jkt parameter is provided in the request body.
Mandatory if the dpop_jkt parameter is missing.
If both are provided, the thumbprint derived from this header must match the dpop_jkt value.

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

Field	Required	Description
`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 section 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 be `https` scheme Custom scheme URLs are no longer allowed. Clients are advised to use universal links for app deep-linking instead. 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 `openid` scope. Must only contain scopes authorized for your Client ID. Unrecognized scopes will result in an error. Refer to 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 `state` returned 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 `nonce` returned 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. This parameter is applicable only for Corppass Login application. If provided for Myinfo Business application, the request will be rejected. Refer to 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. This parameter is applicable only for Corppass Login application. If provided for Myinfo Business application, the request will be rejected. 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 `DPoP` header is provided. Mandatory if the `DPoP` header is missing. If both are provided, the thumbprint derived from the `DPoP` header must match the `dpop_jkt` value. 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 Demonstrating Proof of Possession section for more details.

### Sample Request ```http POST /request Content-Type: application/x-www-form-urlencoded DPoP: client_id=51YUlwazLASM7aqMiBNW &client_assertion=eyJ... &client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer &code_challenge=VQbq2FQzvY12kTkE-FoLmGHim5W7LRknTNYTUKuCKcE &code_challenge_method=S256 &response_type=code &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcallback &scope=openid%20authinfo &state=5de6a954-a762-4975-a8f4-b692cc35b964 &nonce=4a0bb161-e3bb-4a56-9d75-ebea5de7a32c &acr_values=urn:singpass:authentication:loa:2 &authentication_context_type=APP_AUTHENTICATION_DEFAULT &authentication_context_message=login%20as%20corporate%20user &dpop_jkt=boPCS... ``` ## Success Response If the request is valid, Corppass registers the provided parameters and returns a JSON response containing a `request_uri`. ### Response Body

Field Type Description

Field	Type	Description
`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.

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 ```json { "request_uri": "urn:ietf:params:oauth:request_uri:h8YQPVV0Dgm5MGaD_koAm", "expires_in": 60 } ``` ## 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

Field Type Description

Field	Type	Description
`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

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

Error Code	HTTP Status	Error Description
invalid_request	400	This may be due to one of the following: A required request parameter is missing. A request parameter is malformed or does not meet the expected format. Unsupported parameters are included for the selected product (e.g. Corppass Login app parameters used in MyInfo Business requests). The client’s JWKS endpoint is not reachable. The TLS cipher suite used for the connection is not compliant with FAPI 2.0 security requirements. Please ensure that: All required parameters are provided and correctly formatted. Only parameters applicable to the intended product are included in the request. Your JWKS endpoint is accessible and returns a valid key set that complies with the required specification.
invalid_client	400 / 401	This may be due to one of the following: Missing client credential Invalid client credential Expired client credential Improperly formatted client credential or assertion (e.g., malformed JWT) The client’s JWKS does not contain the required signing key Please ensure that: The client credential is present, valid, and not expired Your JWKS endpoint is accessible and returns a valid key set that complies with the required specification.
invalid_scope	400	The requested scope is invalid, unknown, malformed, or exceeds the scope granted to the client.
invalid_dpop_proof	401	This may due to the one of the following: The DPoP proof is expired. The DPoP proof is malformed. The DPoP proof failed signature verification. The DPoP proof contains missing or invalid required claims. Please ensure that: The DPoP proof is correctly structured and signed using the client's private key. The DPoP proof complies with the required specification.
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 ```json { "error": "invalid_client", "error_description": "Client authentication failed due to a missing, invalid, expired, or improperly formatted client credential or assertion.", "state": "5de6a954-a762-4975-a8f4-b692cc35b964" } ``` ## 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**](/docs/singpass-developer-docs/corppass-and-myinfo-business/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/2.-authorization-endpoint.md) **to redirect the user and obtain the Authorization Code.** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.developer.singpass.gov.sg/docs/singpass-developer-docs/corppass-and-myinfo-business/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/1.-pushed-authorization-request-par-endpoint.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.