| Parameter | Description | Data type |
|---|---|---|
response_type | The authorization processing flow to be used. | Only the value code is supported, as mandated by FAPI2.0 specifications. |
scope | A space-delimited string, representing a list of scopes that you are requesting.
| A space-delimited string representing a list of scopes. For Myinfo apps, See our Data Catalog for the allowed values. For Login apps, there are some basic scopes that are allowed. The scopes are The |
state | A session-based, unique, and non-guessable value that you should generate per auth session. This is used to mitigate Cross-Site Request Forgery (CSRF) attacks. This parameter should be uniquely generated for each request and set by your backend. The generated value should be persisted in the backend and associated with your user's session, as it will be needed later. | A string with a maximum length of 255 characters. It must match the regular expression pattern [A-Za-z0-9/+_-=.]+. |
nonce | A session-based, unique, and non-guessable value that you should generate per auth session. This is used to mitigate replay attacks. Just like the | A string with a maximum length of 255 characters. We recommend using a randomly-generated version 4 UUID for this purpose. |
client_id | The client ID of your registered client, provided by Singpass during app onboarding. It is the App ID found at the top of your app configuration page | A 32-character case-sensitive alphanumeric string. |
redirect_uri | The URL that Singpass will eventually redirect the user to after the user completes the login process using the Singpass App. The value will be validated against the list of redirect URLs that were pre-registered with Singpass during onboarding. | URL |
acr_values | A string indicating your preference on the level of assurance required for this authentication. Multiple values, in descending order of preference, may be provided as a space-delimited string.
| Optional. The possible values are:
|
client_assertion_type | The type of client assertion. | Must be the string urn:ietf:params:oauth:client-assertion-type:jwt-bearer, as mandated by OIDC specifications. |
client_assertion | Your client assertion, which is used for authentication. Refer to Generation of Client Assertion for instructions on how this should be generated. | A string containing the signed JWT. |
| Parameter | Description | Data Type |
|---|---|---|
authentication_context_type | A value selected from a predefined list describing the type of transaction that your user is performing the authentication for. This will be used for anti-fraud purposes. | Mandatory and only allowed for Login apps, The list of possible values is provided below. |
authentication_context_message | A string value providing context on what users are performing authentication for. This will be displayed to users when they are performing authentication. For guidance on writing authentication messages, refer here. All messages are subject to audit and compliance monitoring. | String, with a maximum length of 100 characters. The allowable characters are Optional, and allowed only for Login apps. |
redirect_uri_https_type | This value describes the type of redirect that you intend to perform. You should specify this as app_claimed_https if you are performing a redirection to a mobile app via an App-claimed https URL. | Either This field is optional; it defaults to |
app_launch_url | This value is only required if your authentication journey starts and ends for an iOS mobile app. This should be an iOS App Link which will bring the user back to your application after they complete authentication on the Singpass app. | Optional. only applicable for iOS mobile app integration |
| Parameter | Description | Data type |
|---|---|---|
error | An error code identifying the type of error that has occurred. | This will be an enum value. The possible values are detailed below. |
error_description | A human-readable text description of the error. | String. This is optional. |
error_uri | URI of a web page that includes additional information about the error | URL. This is optional. |
state | This will be the same state parameter passed in the authorization request. | A string with a maximum length of 255 characters. It must match the regular expression pattern [A-Za-z0-9/+_-=.]+ |
| error | What this error indicates |
|---|---|
invalid_request | The request had missing or invalid parameters. You should ensure that all the parameters follow the specifications listed above. This error will also be returned if you did not send either the DPoP header or the dpop_jkt parameter. |
invalid_client | This error may occur if your client assertion could not be verified. This is most commonly caused by a malformed JWKS, or an incorrectly generated client assertion. Refer to our guides on client assertions and JWKS, and make sure that your implementation follows both of these guides. |
invalid_scope | The scope parameter that you have provided is invalid. This is typically caused if you did not include the openid scope, or if you are requesting for a scope which your app is not allowed to request.If requesting for a new scope, you will need to edit your app and add the new scope into the list of your app's allowed scopes. |
invalid_dpop_proof | The DPoP header which you have provided is invalid, expired, or malformed. Read our DPoP guide and ensure that your implementation follows the instructions in the guide. |
server_error | The server encountered an unexpected error. You should check This error can potentially be caused by your JWKS endpoint not being reachable. Read our guide on JWKS and ensure that you follow the requirements. In particular, your JWKS endpoint must be publicly accessible and should respond in a timely manner. If the cause was not your JWKS endpoint, you may perform up to 3 retries using an exponential backoff strategy. If the request still fails, you should guide users to alternative authentication methods. |
temporarily_unavailable | The server is temporarily unavailable to handle the request. You may perform up to 3 retries using an exponential backoff strategy. If the request still fails, you should guide users to alternative authentication methods, or to guide them to try again some time later. |
The client ID of your registered client, provided by Singpass during app onboarding. It is the App ID found at the top of your app configuration page.
This must be the same client ID that you passed in the request body of the pushed authorization request.
| | `request_uri` | The `request_uri` returned by the pushed authorization request. | Once you have redirected the user to the authorization URL, the next step would be to wait for the user to complete authentication. Once they complete authentication, they will be redirected back to the `redirect_uri` that you specified. View the next page to understand how to handle the redirect.