5. The Userinfo Request

This step is applicable only to Myinfo (v5) apps.

The final step in the Singpass authentication flow is the userinfo request. This involves making a GET request to our userinfo_endpoint (as defined in our OpenID configuration) to retrieve user information. To do this, you will need an access token (obtained from a successful token request)

The endpoint will only return information based on the scopes that you have requested when making the authorization request.

Request

Just like the authorization request and token request, you will need to include the DPoP header when making the /userinfo request. You will also need to include your access token in the Authorization header. The access token should be prefixed with DPoP , as shown in the sample request below.

No query parameters are required for this request.

Sample request
GET /userinfo HTTP/1.1
Host: id.singpass.gov.sg
Authorization: DPoP eyJ0eXAiOiJhdCtqd3QiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiJ1c2VyLWphbmUtZG9lIiwiYXVkIjoiaHR0cHM6Ly9hcGkuZXhhbXBsZS5jb20vZGF0YSIsImV4cCI6MTc1NjczMDM4MCwiaWF0IjoxNzI1MTk0MzgwLCJqdGkiOiJ0eC0xMjMtYWJjIiwiY25mIjp7ImprdCI6Ik93SWlGaVl2T0NXRkpiV1hlbUdUZzRtU1NYQkNwZk9NaFhRV21XOTBVSEEifX0.dGhpcy1pcy1hLXBsYWNlaG9sZGVyLXNpZ25hdHVyZS1hcy1pdC1yZXF1aXJlcy1hLXByaXZhdGUta2V5
DPoP: eyJhbGciOiJFUzI1NiIsInR5cCI6ImRwb3Arand0IiwiandrIjp7Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJ4IjoiQXNWakh4elZ4MURaNnNKcEpzUnM2ek5YYXFmcFR3UmNfcXV0bWw0aEFJQSIsInkiOiI0SkhwVVZDRE5DaXhOTW9OclIzSElodFRzTWNfMF9NcmdpMzJxR3VoUkQ4In19.eyJqdGkiOiIyZmM3Y2Q4ZC0xN2IzLTRlYTUtYTg4ZC1lZWM0NTY5M2JhZDQiLCJodG0iOiJHRVQiLCJodHUiOiJodHRwczovL2lkLnNpbmdwYXNzLmdvdi5zZy91c2VyaW5mbyIsImlhdCI6MTc1NjcwODI0N30.wBYjFQRzY2o5aG82LjR1X8qT9bZ-jK3c7hI5fE0gP9vR_7sU6tW5xV4yZ3aB2cE1dF0eG9hI8jJ7kL6mN5oP4qR

Response

Successful Response

The response body of a successful response will contain a JSON Web Signature (JWS), which is also encrypted via JSON Web Encryption (JWE), represented in compact seralization form. This is the same encryption and signature scheme that was used in our ID token encryption, so you can decrypt and verify the response in exactly the same manner.

The decrypted (and decoded) response is a JSON object with the following fields:

Field
Description
Data Type

person_info

The personal data of the user. The information returned in this field depends on the scopes that were requested in your authorization request.

A JSON object that follows the Myinfo Get Person response. You can also download the OpenAPI specifications for this property below.

iss

The issuer identifier of our authorization server. This is identical to the iss returned in the ID token.

String

iat

The unix timestamp at which we issued this JWT.

String

sub

The principal that is the subject of the JWT. Contains a globally unique identifier for the user. This is identical to the sub returned in the ID token.

String

aud

The client ID of your registered client, provided by Singpass during app onboarding.

A 32-character case-sensitive alphanumeric string.

The specifications for the person_info property is also available in OpenAPI format

The examples below show how the response would look like if openid uinfin name were the requested scopes.

Sample encrypted response (this is a JWE)
Sample decrypted response (this is a JWS)
Sample decoded response payload

Person Information OpenAPI Specification

This OpenAPI YAML file provides the full technical specification for Myinfo person data fields and scopes. It helps developers understand what information can be retrieved from Myinfo and how each field is structured.

The specification includes:

  • Available Myinfo data scopes and attributes

  • Field names and descriptions

  • Value types (e.g. string, number, array, object)

  • Maximum field lengths and formatting requirements

  • Accepted values and validation rules

  • Example API responses

  • Government verification indicators

  • Display and implementation guidance

Developers may refer to this specification to understand:

  • What are the value types and maximum lengths for each field

  • What information is returned for each Myinfo scope

  • How nested objects and arrays are structured

  • Which fields are editable or government-verified

  • The expected response format for Myinfo APIs

This serves as the technical reference for applications integrating with Myinfo APIs.

Error Response

If there was an error with the request, we will instead return a response body in application/json format with the following parameters:

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.

These parameters will also be returned in the WWW-Authenticate header if the error is invalid_request, invalid_token, or invalid_dpop_proof.

Sample error response body
Sample WWW-Authenticate header

Possible error values

The table below lists the possible values of error that we may return:

error
What this error indicates

invalid_token

The access token is invalid or has expired. Note that the access token has a lifetime of 30 minutes.

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.

invalid_request

This could be due to one of the following:

  • Your JWKS endpoint is not reachable, or the JWKS being returned is malformed., Read our guide on JWKS and ensure that you follow the requirements.

  • You are trying to retrieve Myinfo data for a Singpass Foreign Account user, which is not possible.

server_error

The server encountered an unexpected error. You should check error_description to understand what was the cause of the error. When you encounter this error, you may perform up to 3 retries using an exponential backoff strategy. If the request still fails, you should guide users to alternative form-filling methods.

upstream_depedency_error

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.

Last updated

Was this helpful?