After successful authentication, Singpass will return an authorization code
and state
back to your application redirect URL as described under the section Invoke Authorization Endpoint.
The value of the code parameter received will be used to call the Singpass token endpoint to exchange for the security tokens (i.e. ID token and access token) per the authorization flow.
Staging | Production |
---|---|
Token Endpoint can only be called from server-side code.
Create a new server-side code file called api.js and copy the logic needed for login from the code panel. This file contains the function to generate the client assertion as explained in section Setup Client Assertion. For the demo Singpass application, the api.js file is within the Singpassdemoappserver code.
Do not use the sample private key as it has been compromised. For demo purposes, all keys have been displayed but It is recommended not to directly store your private key/ public key in your code, you should follow the best practices to store them in either Database or Secure Storage, or perhaps store them as environment variables, or in a config files, should avoid hardcoding.
Update request parameters accordingly for the token endpoint with the following attributes:
Create attributes for all the request parameters and update them accordingly. For the demo singpass application, update all the following fields within the api.js file.
After configuring the token request parameter, and calling the server function through a postman call by providing the code retrieved from the authorization endpoint response, upon successful authorization, your application will be responded to with an ID token and access token like the following example.
After receiving the ID token, your application needs to decrypt the ID token with your encryption JWT private key to obtain the NRIC/UUID. For the demo singpass application, the following code works as the decrypt function.
If you have received the response successfully, congratulations you have successfully integrated with Singpass.
Generally follows OIDC error response specifications. For more information, please refer to Token Error Response specifications.
Key | Description | |
---|---|---|
Key | Description |
---|---|
client_id
This should be client_id
of the registered client provided in the Application configuration for each Application
redirect_uri
The redirect URL being used in this auth session. The value will be validated against the list of redirect URIs that were pre-configured in Application Configuration.
grant_type
The type of grant being requested. This must be set to authorization_code
code
The code
issued earlier in the auth session
client_assertion_type
This MUST be set to urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertion
A JWT identifying the client as setup in the previous step
access_token
A random string that isn’t used.
token_type
The type of token being requested, Bearer only so far.
id_token
The ID token with relevant claims in JWT format signed by the Singpass. Note that the example response body shows a JWS (3-part structure separated by dots), but the format will differ for a JWS in JWE (5-part structure). Refer here for more details about the ID token structure.