Custom Integration
You will need to write your own custom sgID integration if your app uses a programming language that sgID does not have a SDK for. This page provides a guide for how to implement this custom integration.
When a user tries to log in to your application with sgID, you need to:
Step 1: Generate a PKCE pair
Proof Key for Code Exchange (PKCE) is an OAuth 2.0 enhancement and protects against various potential vulnerabilities such as authorization code interception. A unique PKCE pair must be generated for each request and consists of a code_verifier
and a code_challenge
.
Code verifier
The code_verifier
should be a high-entropy cryptographic random string with an ABNF as follows
Code challenge
The code_challenge
should be generated from the code_verifier
using the S256
code challenge method. The S256
transformation is described below together with the ABNF of the code_challenge
.
sgID only supports the S256
code challenge method as the plain
method is insecure (see the PKCE RFC) and only exists for backwards compatibility reasons.
The code_challenge
must be sent to the sgID authorization server when initiating an authorization request, whereas the code_verifier
must be provided when exchanging the OAuth authorization code for an access token. This allows the sgID server to verify that the server exchanging the access token is the same server that initiated the request!
Here are some cryptography libraries you could use to generate these values:
Node.js - pkce-challenge
Python - pkce
Step 2: Create an authorization URL to redirect to
To allow your user to login into your app with sgID, you need to create an sgID authorization URL.
Your app should redirect your user's browser to this authorization URL, which will display a QR code that they can scan to authenticate with the Singpass mobile app:
You will need to supply the following query string parameters:
response_type
Must be set to code
because sgID only supports the authorization code flow
client_id
redirect_uri
scope
A URL-encoded string of the scopes your client will request for
code_challenge
The code challenge used for PKCE. Used to prevent authorization code interceptions and cross-site request forgery (CSRF)
nonce (optional)
state (optional)
A unique and non-guessable value associated with each authentication request about to be initiated
Step 3: Exchange auth code for access token and ID token
After the user authenticates with the Singpass mobile app, the user's browser will be redirected back to the callback URL you provided, together with the authorization code and a state value.
To exchange the code
for the access token and ID token, make a POST
request to
with the following request body parameters:
client_id
client_secret
code
The value returned to you as part of the callback URL
grant_type
Must be set to authorization_code
redirect_uri
code_verifier
A cryptographically random string that was used to generate your code challenge in the authorization request.
You should receive a response with the following attributes:
access_token
Access Token to be used with retrieving the encrypted payload from user info endpoint
id_token
JWT token with the associated user claims. Encodes the following:
iss (hostname)
sub (end user's unique identifier)
aud (client id)
nonce (only returned if provided in authorization URL)
exp (seconds before auth request and access token expires)
iat (timestamp at which id token was issued)
Example JSON response body:
The ID token is signed with sgID's private key. It is highly recommended that you verify the ID token with our public keys, which can be found here.
Step 4: Request for user info with access token
Once you have the access token, you can use it to request information about the user corresponding to the scopes that you requested. To do so, make a GET
request to
with the access token you received in the previous step. Example request:
You should receive a response with the following attributes:
sub
End user's unique identifier for your client - This is the same value as the sub
claim in the id_token
returned from the previous response.
Note that as part of sgID's privacy-preserving measures, each end user's unique identifier is different for each sgID client
key
An AES-128-GCM symmetric key, or a block key, that is encrypted with your client's RSA-2048 public key.
data
JSON object which contains the data you requested in your application scope. To prevent sgID from reading the data, the payload is encrypted with the block key referenced in the definition for the key
attribute in the same response body.
Example JSON response body:
Step 5: Decrypt the user info payload
As part of sgID's privacy-preserving measures, user data is transmitted in encrypted form, so that the sgID server is unable to read the data being transacted. The data is encrypted with a block key, which itself is encrypted with your client's public key so that only your client has access to the block key.
Therefore, to obtain the user data in plaintext, you will need to:
Decrypt the
key
received from the user info response with your client's private key. This will give you the block key.Decrypt the
data
received from the user info response with the block key you have just obtained.
Example decryption:
Example of decrypted data:
Last updated