# About Corppass Corppass is the Singapore Government’s corporate authorisation system that enables entities to securely manage their employees’ access to digital services for corporate transactions. It allows businesses, non-profit organisations, and other entities to transact digitally with Singapore Government agencies and participating private sector services. Corppass leverages Singpass to authenticate individual identities. By providing a trusted and unified corporate authentication and authorisation framework, Corppass supports Singapore’s Smart Nation objectives and the Government’s goal of delivering secure, reliable digital services for both citizens and businesses. # Corppass Login ### What is Corppass Login? The Corppass Login enables authorised individuals to securely access and transact with digital services on behalf of their organisations. It provides organisations with a trusted login mechanism that verifies both the user and their permissions to act for a specific entity, ensuring secure and accountable business transactions. #### How Corppass Login enhances your digital service? * **Enables users to act on behalf of organisations**\ Support business transactions by allowing authorised individuals to access your digital services as verified representatives of their organisations. * **Tap on a trusted corporate access framework**\ Integrate a widely adopted login mechanism used across government and business services, without building your own authorisation system. * **Access an established ecosystem of organisations**\ Reach companies and authorised users already using Corppass to transact digitally.

Users log in with Singpass as authorised Corppass representatives, based on permissions granted by their entity administrators

# Key Principles Partners are to comply with Corppass Login key principles for your integration and submission of documents. ### Authentication and Authorisation #### Use Corppass Login as an authentication and authorisation service * Corppass Login should be used to verify both the identity of the user and their authorised role / permissions for the digital service. #### User identification using UUID * While Corppass provides both NRIC/FIN and UUID, digital services are recommended to use the Universally Unique Identifier (UUID) to identify users. * UUID avoids handling sensitive NRIC/FIN information and provides a stable, privacy-friendly identifier for authentication and authorisation. #### Alternative login options * Where feasible, offer support for users who may require non-Corppass login options to access your service. *** ### Data Use and Compliance #### Comply with PDPA and applicable legislation * Protect, retain and transfer any data retrieved according to the Personal Data Protection Act (PDPA), relevant industry regulations and applicable legislation. * For collection of National Identification Numbers, refer to the advisory guidelines from PDPC [here](https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Advisory-Guidelines/Advisory-Guidelines-for-NRIC-Numbers---310818.pdf). #### Use data and credentials for lawful purposes * Ensure that any access or usage of Corppass credentials and retrieved data is strictly for authorised and lawful purposes. # Pricing Plan **Government Agencies**\ The [official government pricing plan](https://gccprod.sharepoint.com/sites/GOVTECH-digitalgov/Singpass-and-Corppass/SitePages/Price-Plan.aspx) is available on GSIB devices. **Entities affiliated with Government Agencies**\ You may check with your respective Ministry or Agency counterparts for pricing details. **All other entities**\ For any pricing-related queries, please submit a request via the [Partner Support Portal](https://partnersupport.corppass.gov.sg). # Corppass Design Guidelines The **Corppass** brand is more than just a name - it reflects our mission, values, and commitment to enabling secure, seamless digital transactions for businesses and organisations in Singapore. Consistency in branding, design, and UI elements strengthens trust, recognition, and a lasting connection with our audience. {% content-ref url="/pages/caqNEt78EeDvzQgP3Hda" %} [Brand Guidelines](/products/corppass-login/corppass-design-guidelines/brand-guidelines) {% endcontent-ref %} {% content-ref url="/pages/d0AdlZlCxDs0zAGowDlk" %} [Button Guidelines](/products/corppass-login/corppass-design-guidelines/button-guidelines) {% endcontent-ref %} Adhering to these guidelines ensures a professional, accessible, and user-friendly experience. # Brand Guidelines Our brand guidelines ensure a strong and unified brand presence, whether you are crafting digital experiences, or representing Corppass in any way. Use only approved brand assets to uphold our integrity, professionalism, and trustworthiness. **Download Corppass logo:** {% file src="/files/kCmRGlwtZMfIYmhR5eAS" %} *** ## Logo
The **Corppass** logo uses a customised lowercase typeface for consistency and recognisability. The stylised black ‘o,’ derived from our ‘key figure,’ symbolises secure access to services. Optical kerning, refined weight, and defined clear space ensure clarity and recognisability across all sizes and contexts. {% hint style="info" %} Always write '**Corppass'** as a single word with an uppercase ‘**C**’—never as ‘CorpPass’ or other variations. {% endhint %} *** ## Logo Variations

Full colour

Black

White

Our master logo is available in two colour configurations.
 {% hint style="info" %} **Full colour:** The entire logotype is in Corppass blue except for the black ‘o’.
 **Single colour:** The entire logotype can be used in either Corpppass blue, black or reverse white. {% endhint %} *** ## Usage on background
We recommend to use the full colour logo whenever possible. It should be used on either white or light grey background only. The single colour logos should only be used on either Corppass blue, light blue or black background. For photograph backgrounds, the single colour logo in reverse white should be used. *** ## Do not
*** ## Scale
Our master logo is designed to scale for small sizes on print and screen. The clearspace around the logo is equal to the x-height of the ‘o’. Minimum sizes of the master logo:\ Digital: **80 pixels** wide\ Print: **18mm** wide # Button Guidelines Please adhere to the following guidelines when recreating the Singpass button. **Download** **Singpass logo:** {% file src="/files/ZRahDRNTmxF7O4TWvBQT" %} #### **Singpass button types** By default, use the white fill button to pair it with your service’s interface. Alternatively, you may use the red fill button if it’s suitable. * White-filled button: **#FFFFFF** * Red-filled button: **#F4333D**
**Singpass button for Corppass user** We recommend adding 'as Corppass user' when pairing with the Singpass button to help users quickly identify their login role.
#### Font usage for button label By default, please use **Poppins** at 16px size. Alternatively, you may use your brand’s typeface. San serif is highly recommended for this button to better match the Singpass logo. Download Poppins Bold on [Google fonts](https://fonts.google.com/specimen/Poppins).
#### Label If you are using the label ‘**Log in**’ must be kept as two words.
**Accessibility: Aria labels for screen readers** Please ensure that the Singpass logo has a aria-label to ensure that screen readers will read it as “Sing pass” to avoid it reading out the entire word as ‘S-i-n-g-p-a-s-s’.
**Singpass logo size** Match the **x-height** of the label as close as possible to ensure visual balance and proportion.
**Button colour** To ensure brand recognition and consistency, use the **white-filled** or **red-filled** **buttons** as stated below. Avoid using colours other than white-filled or red-filled buttons.
**Border stroke** When using the white-filled button, please ensure to adhere to the specs stated below. * Border colour: **#C8C9CC** * Border width: **1px**
**Border radius** Ensure that the border radius of Singpass button matches your button.
**Hover state** Please adhere to the following colours, and avoid using another hover state styling. * White-filled button hover colour: **#F5F5F7** * Red-filled button hover colour: **#B0262D**
**Width and height** Please ensure that the Singpass button visually matches your primary button with the following:

Width: Fill to match your primary button width.

Height: Match your button height.

# Getting Started Before integrating Corppass Login, ensure your organisation has access to the [Corppass Developer Portal (CDP)](https://developer.corppass.gov.sg/) and that your use case meets the onboarding requirements. ### 1. Get Access to the Corppass Developer Portal To begin, request access to the Corppass Developer Portal for your organisation. This will allow you to create and manage staging and production applications for Corppass Login. 👉 [How to get access to Corppass Developer Portal](/corppass-developer-portal-cdp/user-guide/getting-started) ### 2. Create a Staging Application Create a Corppass Login Staging application on the Corppass Developer Portal. The staging environment allows you to: * Configure your application. * Test your integration safely before going live. 👉 [How to create a Corppass Login application](/corppass-developer-portal-cdp/user-guide/portal-features/creating-digital-service) ### 3. Set Up Your Test Environment Once your Staging application is ready, begin testing your Corppass Login integration. Use a Corppass staging test account to verify that authorised users can log in and transact on behalf of the entity. 👉 [How to set up a staging Corppass account](https://partnersupport.corppass.gov.sg/hc/en-sg/articles/49809641612185-I-need-staging-test-account-for-Corppass-testing) ### 4. Begin Your Integration With your Staging environment and test accounts ready, start building your Corppass Login integration. 👉 [Integrate with Corppass Authorization API (FAPI 2.0)](/technical-specifications/corppass-authorization-api-fapi-2.0) ### 5. Prepare for Production Before creating your Production application: * Review the relevant service agreements. 👉 [Review Corppass Agreement](https://www.corppass.gov.sg/corppass/common/terms) ### 6. Create Your Production Application Once you are ready: * Create your Production application in Corppass Developer Portal. * Configure your application. * Submit your Production application for approval. * Publish your digital service once your application has been approved. You can begin testing using your Production credentials after your submission has been approved. 👉 [How to create a Corppass Login application](/corppass-developer-portal-cdp/user-guide/portal-features/creating-digital-service) # Myinfo Business ### What is Myinfo Business? Myinfo Business enables organisations to retrieve verified corporate and applicant data from government sources for seamless digital transactions. Authorised users can consent to allow digital services to access relevant information about their organisation or applicants, reducing manual data entry and supporting faster, more accurate business processes. #### How Myinfo Business enhances your digital service? * **Reduce manual data entry and paperwork**\ With user consent via Corppass, services can retrieve verified corporate and applicant data directly, eliminating repetitive form-filling and minimising errors. * **Access authoritative, verified data**\ Data comes from trusted government sources, enabling faster onboarding, compliance checks, and accurate verification of business details. * **Streamline transactions and approvals**\ Pre-filled, verified data allows digital services to process applications and approvals more efficiently, improving the experience for both corporate users and applicants. * **Minimise supporting documents**\ By leveraging verified data, digital services can reduce the need for physical documents to complete transactions, further simplifying the user journey. # Key Principles Partners are required to comply with Myinfo Business key principles for your integration and submission of documents. ### Requesting and Using Data #### Requesting only what you need * Only retrieve business data necessary for your service. * Do not collect data unless required for regulatory, compliance, or operational purposes. * Each data request should support only a single business purpose. #### Comply with PDPA and applicable legislation * Protect, retain and transfer any data retrieved according to the Personal Data Protection Act (PDPA), relevant industry regulations and applicable legislation. * Ensure usage aligns with the consent provided by the authorised business representative. #### Use data for lawful purposes * Use the data items retrieved through Myinfo Business strictly for lawful purposes. * The data must only be used for the intended service or transaction for which the business provided consent. *** ### Designing your User Journey #### Display data as-is * Data retrieved from Myinfo Business APIs should be displayed exactly as received. * Government-originated data should remain un-editable to preserve accuracy and data integrity. * User-provided information may remain editable where appropriate. * Displaying data as-is helps assure users that the correct data has been retrieved and encourages them to update official records if information is outdated. #### Reduce supporting document upload * Business data retrieved from verified government sources (e.g. entity information, registered address, business ownership details) should be assessed for suitability as an alternative to requesting supporting documents for verification (e.g., ACRA business profile, government-issued licence, CPF contribution history, Notice of Assessment). #### Store data only if submitted * Data should be purged if the application or form is not successfully submitted. * For “Save-as-draft” features, unsubmitted data should be purged periodically. #### Provide alternative options * Partners are encouraged to provide an alternative option for users who prefer not to use Myinfo Business. #### Indicate availability and eligibility * Clearly indicate that Myinfo Business is available for your service. * Specify who is eligible: ACRA-registered businesses, and authorised individuals with a Corppass user account linked to an NRIC/FIN. #### Highlight benefits to businesses * Present the benefits of using Myinfo Business, such as faster applications, reduced manual form-filling, fewer document uploads, and more accurate business data. #### Follow design guidelines * Ensure your implementation adheres to the prescribed [Design Guidelines](/products/myinfo-business/design-guidelines) to provide a consistent and recognisable user experience when using Myinfo Business. # Pricing Plan Myinfo Business is currently provided free of charge. Any future changes to pricing will be communicated in advance and available to view from the [Singpass Developer Portal](https://developer.singpass.gov.sg/) after you log in. # Design Guidelines Singapore residents use Singpass every day to access essential services, from government to financial transactions and healthcare. This is made possible as thousands of partners across the public and private sectors have integrated with Singpass to make services more seamless for their customers. Help us protect our brand, by following these guidelines and only using approved brand assets (any logos or images found elsewhere on the web are not approved for use). {% content-ref url="/pages/tD2bcHz65TXbDOIv7YRz" %} [Singpass Brand Guidelines](/products/myinfo-business/design-guidelines/singpass-brand-guidelines) {% endcontent-ref %} {% content-ref url="/pages/hZhR7C3p8wdbfVgEqhM8" %} [Button Guidelines](/products/myinfo-business/design-guidelines/button-guidelines) {% endcontent-ref %} # Button Guidelines ## Overview This guide covers how to display the Singpass button correctly. It includes the approved button for Myinfo Business, approved labels, visual style and accessibility considerations. Following these guidelines helps prevents common implementation issues, and ensure a clear user experience with what users already know and trust. **Download asset:** {% file src="/files/g9KeLiRgbDfKvdKbRsVO" %} *** ### Approved button label The button label communicates what will happen when users click the button. **These are the** **only approved labels for the Singpass button**. Choose the one that best reflects the user's action in your flow, and do not create your own variations. **Download Singpass button:** {% file src="/files/v3NPtLBjjqKUpgDbqqze" %}
Use case typeUse whenButton
Registration and Sign upUsers are signing up or registering for your service

Example: Creating a new banking, telco, or service account

ApplicationUsers are applying for a product or service
Examples: Applying for a credit card, loan, or grants
Identity verification

The primary purpose is to confirm the user’s identity

Examples:

  • Verifying identity before accessing sensitive features
  • Performing KYC checks before allowing further actions
Retrieval or update of Information

Users are asked to fill in their details

Examples:

  • Pre-filling details in a form
  • Refreshing previously saved information
Others

Singpass is used as a step within a larger flow. The action is to proceed, not to apply or verify

Examples:

  • Booking an appointment
  • Moving to the next step before details are shown
*** ### Button colour Use colour to indicate emphasis and ensure the Singpass button is clearly visible in your interface. Choose a variant that provides sufficient contrast with the background and reflects the importance of the action. #### White with outline (Default) * White background `#FFFFFF` with grey border `#AAABAD` * Dark grey text `#141414` Use when a lower visual emphasis is needed or when pairing with other primary actions.
#### White (for dark mode) * White background `#FFFFFF` * Dark grey text `#141414` Use this variant when your interface has a dark background. The white button is the only approved variant for dark surfaces, do not use the other variants on dark backgrounds as they are designed for light interfaces.
#### Black * Dark grey background `#141414` * White text `#FFFFFF` * Full white Singpass logo Use for primary actions on light backgrounds. #### Red * Singpass Red background `#D93841` * White text `#FFFFFF` * Full white Singpass logo Use to reinforce Singpass branding.
#### Don't Don't use colours outside the approved variants, including gradients or modified brand colours.
Don't use a colour variant that clashes or blends with nearby buttons.
#### Button states The Singpass button has three states. Each variant handles them the same way, only the background colours differ. {% tabs %} {% tab title="White with outline" %}
StateButton background colour [hex code]Border colour [hex code]Font colour [hex code]
DefaultWhite: #FFFFFFGrey: #AAABADBlack: #141414
Hover
Light grey: #F5F5F7Grey: #AAABADBlack: #141414

Disabled

Grey: #E8E9EBGrey: #AAABADGrey: #AAABAD
{% endtab %} {% tab title="White (dark mode)" %}
StateButton background colour [hex code]Font colour [hex code]

Default

White: #FFFFFFBlack: #141414

Hover

Light grey: #F5F5F7Black: #141414

Disabled

Grey: #E8E9EBLight grey: #AAABAD
{% endtab %} {% tab title="Black" %}
StateButton background colour [hex code]Font colour [hex code]

Default

Black: #141414White: #FFFFFF

Hover

Dark grey: #3B3C3DWhite: #FFFFFF

Disabled

Grey: #E8E9EBLight grey: #AAABAD
{% endtab %} {% tab title="Red" %}
StateButton background colour [hex code]Font colour [hex code]

Default

Red: #D93841White: #FFFFFF

Hover

Dark red: #B0262DWhite: #FFFFFF

Disabled

Grey: #838487White: #FFFFFF
{% endtab %} {% endtabs %} *** ### Font usage #### Button label By default, use Poppins Bold at 16px. If you prefer to use your brand typeface, choose a sans-serif font to better match the Singpass logo. Download Poppins Bold on [Google fonts](https://fonts.google.com/specimen/Poppins).
*** ### Singpass logo For **“Singpass”**, use the official Singpass logo within the button.\ This helps users quickly recognise and trust the action. Avoid replacing it with plain text or recreating it in another typeface. **Download Singpass logo:** {% file src="/files/xSbMtoNg8liddIcUrfe4" %}
#### Singpass logo size The Singpass logo must have a minimum height of 14px. Do not scale it smaller than this as it will become illegible on smaller screens.
* Match the x-height of the label as close as possible to ensure visual balance and proportion.
*** ### Button size Keep the internal padding consistent so the logo and label always have breathing room. The button should never feel cramped.\ \ **Minimum height:** * Desktop: 40px * Mobile: 44px — applies to native apps and mobile browsers **Minimum internal padding:** * Horizontal: 16px on each side * Space between label and Singpass logo: 4px
*** ### When placing the Singpass button alongside your own buttons Make sure it feels like it belongs — same height, same width, consistent spacing. Here's what works and what to avoid.

Same height as your other buttons. Minimum 40px on desktop, 44px on mobile.

Same width as the other buttons in your layout.

#### Spacing Give the Singpass button room to breathe. Maintain a **minimum of 16px** between the button and any surrounding elements such as buttons, form fields, or body text.
*** ### Border radius You can adjust the corner radius of the Singpass button to match your own. Whether your buttons are fully rounded, subtly curved, or square-cornered, the Singpass button should follow the same style, so it fits naturally into your UI rather than standing out as a third-party element.
*** ### Accessibility: Aria labels for screen readers For screen readers, ensure the Singpass logo is announced correctly.
Provide an accessible label so it is read as **“Sing-pass”**, instead of being spelled out letter by letter ‘S-i-n-g-p-a-s-s’.
# Singpass Brand Guidelines If you are a partner who wants to refer to Singpass or use the Singpass logo in your marketing materials, these are the guidelines for how to do it. When we present our brands in a way that accurately reflects the partnership, it helps to build awareness, recognition, and trust. **Download Singpass logo asset:** {% file src="/files/xSbMtoNg8liddIcUrfe4" %} *** ### Singpass logo The Singpass logo is available in three variants to ensure it remains clear and legible across different backgrounds and contexts.
TypeUse whenVariant
Full colour (Primary)
The default logo.		Use this whenever possible on light or neutral backgrounds.
White (secondary)For use on dark backgrounds where the full colour logo would not be legible.
Black (secondary)For use on high-contrast backgrounds such as red, where neither the full colour nor white logo would stand out clearly.
**Dont's** Don't combine the Singpass name or logos, or any portion of any of them, with other logo, company name, mark or generic terms. Don't edit, modify, distort, rotate or re-colour the logo. Don't use the Singpass logo to imply endorsement from Singpass.

Don't modify the Singpass logo, such as stretching, skewing, or changing the colour.

Don't place the Singpass logo on backgrounds that inhibit legibility. Use white or black backgrounds where possible.

*** ### Logo size
Minimum sizes of the Singpass logo: * Digital: **80 pixels wide** * Print: **18mm wide** *** ### Naming usage Never modify or abbreviate the name 'Singpass'. The 'S' in Singpass is always capitalised. Keep 'Singpass' as a single word. *** ### How to talk about the Singpass brand Ensure you reflect how your service or product integrates with ours in a way that is truthful and precise. * Do use the Singpass name only as a proper noun, for e.g. “Log in with Singpass” or “Sign up with Singpass”. * Don't make statements implying endorsement from Singpass or overstating Singpass’ involvement. *** ### Logo placement For collaborative brand partnerships, the Singpass logo will come first, followed by respective brand partner logo(s). * Clear space should be used between the logos, denoted by the x-height of the ‘i’. * Both logos should be scaled to the same optical size for visual balance. * Both logos should be similarly proportioned. We recommend that you first start by matching the height or width of partner logo(s) to the Singpass logo. # Getting Started {% hint style="info" %} #### Myinfo Business Launch Myinfo Business (v3) is now available for onboarding. All existing applications (v1/v2) must migrate to Myinfo Business v3 by **31 May 2027**, as legacy versions will be deprecated after this date. To ensure continuity of service, we encourage planning and completing your migration early. [Refer to migration guide](/technical-specifications/corppass-authorization-api-fapi-2.0/migration-guides/migration-guide-myinfo-business-v1-v2-to-v3-fapi-2.0) {% endhint %} Before integrating Myinfo Business, ensure your organisation has access to the [Singpass Developer Portal (SDP)](https://developer.singpass.gov.sg/) and that your use case meets the onboarding requirements. ### 1. Get access to the Singpass Developer Portal To begin, request access to the [Singpass Developer Portal](https://developer.singpass.gov.sg/) for your organisation. This will allow you to create and manage staging and production applications for Myinfo Business. 👉 [How to get access to Singpass Developer Portal](https://docs.developer.singpass.gov.sg/docs/singpass-developer-portal-sdp/user-guide/obtaining-access-to-the-singpass-developer-portal-sdp) ### 2. Create a Staging Application Create a Myinfo Business Staging application on the Singpass Developer Portal. The staging environment allows you to: * Configure your application. * Select the required data scopes. * Test your integration safely before going live. 👉 [How to create a staging application](https://docs.developer.singpass.gov.sg/docs/singpass-developer-portal-sdp/user-guide/create-staging-app) 👉 [View Myinfo Business data scopes](/technical-specifications/corppass-authorization-api-fapi-2.0/scopes/myinfo-business-scopes) ### 3. Set up your Test Environment Once your Staging application is ready, begin testing your Myinfo Business integration. Use our ready made test personas to simulate Myinfo Business responses. 👉 [Myinfo Business Test Personas](/testing/myinfo-business-test-personas) ### 4. Begin your Integration With your Staging environment and test accounts ready, start building your Myinfo Business integration. 👉 [Integrate with Corppass Authorization API (FAPI 2.0)](/technical-specifications/corppass-authorization-api-fapi-2.0) ### 5. Prepare for Production Before creating your Production application: * Review the relevant service agreements. * Agree to the Singpass Services Agreement. * Update your billing contact details in Singpass Developer Portal. * Prepare your User Journey. 👉 [Where to review the Services Agreement & Pricing](https://docs.developer.singpass.gov.sg/docs/singpass-developer-portal-sdp/user-guide/view-singpass-service-agreement) 👉 [User Journey Guidelines](/products/myinfo-business/getting-started/user-journey) ### 6. Create your Production Application Once you are ready: * Create your Production application in Singpass Developer Portal. * Specify the purpose of your digital service (e.g., bank card application, loan application). * Configure your application. * Select the required data scopes. * Upload the completed User Journey. * Submit your Production application for approval. You can begin testing using your Production credentials after your submission has been approved. 👉 [How to Create a Production App](https://docs.developer.singpass.gov.sg/docs/singpass-developer-portal-sdp/user-guide/create-production-app) {% hint style="info" %} Note: Production Application approval may take **up to 2 weeks**. Please plan your rollout timeline accordingly. {% endhint %} # Prerequisites Before submitting an onboarding request for Myinfo Business, ensure your organisation and use case meet the following requirements. {% hint style="info" %} **Note:** Myinfo Business is only available to **ACRA-registered entities** with authorised Corppass users. Ensure your service is designed for eligible businesses. {% endhint %} #### Organisation Requirements * Your organisation must be a Singapore-registered entity (government or private sector). * If you operate in a regulated industry, ensure you have the relevant licences or permits. * Prepare your ACRA registration details (or equivalent). * Prepare regulatory licence/permit documentation, if applicable. #### Use Case Requirements * Only request data that is directly needed for your service. * All data scopes must be justified based on your use case. * Ensure your intended use aligns with the [Key Principles](/products/myinfo-business/key-principles), including lawful use, data minimisation, and compliance with PDPA. * Be ready to document this in your [User Journey](/products/myinfo-business/getting-started/user-journey) for submission. #### User Choice Requirements * Provide alternative methods for users who prefer not to use Myinfo Business, such as manual form entry or document upload. # User Journey As part of creating your **Myinfo Business production application**, you are required to submit a User Journey that illustrates how your digital service will use the Myinfo Business API. #### Preparing Your User Journey Use the User Journey template provided for Myinfo Business to illustrate your service flow. {% file src="/files/AaiodyxvTjPp1WOOrYFR" %} Include the following: * **User flow** * Indicate where users trigger Myinfo Business within your application (e.g., provide Myinfo Business button for users to retrieve their profile), following the [Brand Guidelines](/products/myinfo-business/design-guidelines/singpass-brand-guidelines). * Clearly convey the prerequisites for users to access Myinfo Business: * "To use Myinfo Business, ensure you have a Corppass account and are assigned to '\[E-Service Name]' digital service by '\[Organisation Name]' for the entity you are applying for." * Offer an alternative for users to fill in the form manually if they choose not to use Myinfo Business. * **Data scopes** * List all Myinfo Business data items your service will request. * Provide a clear justification for each data scope. * Ensure the request and use align with the [Key Principles](/products/myinfo-business/key-principles), including lawful use, data minimisation, and compliance with PDPA. * **Data display and handling** * Show how retrieved data will appear in your forms or application. * Indicate how your service handles errors when Myinfo Business is unavailable or the retrieval fails. #### Submission Process * Submit your completed User Journey together with your Production application on the [Singpass Developer Portal](https://developer.singpass.gov.sg/). * Your submission will be reviewed for compliance with technical and regulatory requirements. {% hint style="info" %} **Tips for a Successful Submission** * Ensure clarity by clearly indicating where Myinfo Business is invoked and how data will be used. * Keep it concise by including only the relevant steps for your integration. * Verify compliance with [Myinfo Business Key Principles](/products/myinfo-business/key-principles) to ensure alignment. * Follow [Myinfo Business Brand Guidelines](/products/myinfo-business/design-guidelines/singpass-brand-guidelines) in your service’s presentation and user interface. * Plan ahead because Production application approval may take up to 2 weeks, so prepare your submission early. {% endhint %} # FAQ Frequently Asked Questions about Myinfo Business {% content-ref url="/pages/WAYSTv89bfgqWxyi9b4x" %} [FAQ for Partners](/products/myinfo-business/faq/faq-for-partners) {% endcontent-ref %} {% content-ref url="/pages/IvfFOwX5yN5CsglIK7Wc" %} [FAQ for Entity Users](/products/myinfo-business/faq/faq-for-entity-users) {% endcontent-ref %} # FAQ for Partners Frequently Asked Questions about Myinfo Business ### Data Usage
Can I request for more data items than what I need for my digital service? No. You should only request for the data items that you need for your digital service. This is aligned with the guidelines of the Personal Data Protection Act, which instructs the collection of personal data in an appropriate manner for the circumstances. Each request will be reviewed prior to approval.
Can my digital service retrieve data for backend processing without displaying it on the digital form? No. All data retrieved from Myinfo Business must be displayed on the digital form for user verification before submission.
Can I save the retrieved data in the transaction session or cookie, and repopulate the form using the saved data if the user closes the browser and comes back to the digital service? No. To prevent stale data from being mistaken as Myinfo Business data, every profile retrieved must fetch fresh data from Myinfo Business.
Can I depend solely on Myinfo Business to fill up a form? No. Digital services should provide alternatives (e.g., allow manual entry) to support: * Users who choose not to use Myinfo Business. * Foreign users who could not access Myinfo Business. * Temporary service unavailability (e.g., system maintenance).
How should my digital service handle scenarios where the user finds that the verified data retrieved from Myinfo Business is out-of-date? Users should be allowed to manually correct data in the digital form. Previously retrieved Myinfo Business data should not be saved if updated manually. You should also encourage users to update their official records with the relevant registries to ensure future Myinfo Business data is accurate and up-to-date.
What should I do when a user's / entity's data in the business conflicts with the data retrieved from Myinfo Business Assess which dataset takes precedence based on business or regulatory requirements, considering: * Whether the data is retrieved from official government sources. * The timestamp of the data to determine which is more recent.
### Onboarding and Setup
How do I link multiple digital services with Myinfo Business? A new request must be submitted for each digital service with a distinct use case or user journey.
What is the estimated response time after submitting an application request? We will respond to your application request within approximately two weeks of submission.
How long does it take for my application configurations to take effect? Upon successful submission, your application configurations will take effect within 5 to 10 minutes.
Can I change my data items / scopes after submission? Yes. After your original request has been approved, you may edit your application via the "Edit" button, and update your data items / scopes under "Scopes Selection". A revised User Journey must be submitted to reflect the updated data items / scopes with their justifications.
Can I request for custom test personas? No. Custom test personas are not supported. Please use the predefined common personas available [here](/testing/myinfo-business-test-personas) for testing.
*** ### Contact Us If you have any queries or require support, please submit a request via [Partner Support Portal](https://partnersupport.corppass.gov.sg/). # FAQ for Entity Users Frequently Asked Questions about Myinfo Business ### Eligibility
How can my business use Myinfo Business? To use Myinfo Business, your business must be registered on **Corppass** and have an authorised administrator (Corppass Administrator) set up for the entity. Steps to participate: 1. Ensure your business is registered with **ACRA**. 2. Ensure your business as an authorised **Corppass Adminstrator account** set up via the [Corppass Portal](https://www.corppass.gov.sg/portal). 3. The Corppass Administrator assigns which **Singapore-resident users** (NRIC/FIN account holders) can transact on behalf of the business for Myinfo Business digital services. Note that Singpass Foreign Account holders cannot access Myinfo Business. 4. Authorised users can then access the Myinfo Business service via Corppass on behalf of your business. This ensures that only **verified users of your business** can retrieve corporate and personal data securely via Myinfo Business. Refer to [Corppass user guides](https://ask.gov.sg/corppass/questions/cm22qyq7n000l9apo14b7025m) for more details.
How do I know if I am assigned to use Myinfo Business? You can use Myinfo Business if you are a **Singapore resident** with a valid Singpass account (NRIC/FIN) authorised to transact for your business via Corppass. Typically, your Corppass Administrator assigns you this access. Eligible users include: * Singapore Citizens and Permanent Residents. * Eligible pass holders (e.g. Employment Pass, S Pass, Work Permit, Student Pass, Dependant’s Pass, Long Term Visit Pass, Immigration Exemption Order holders). To confirm your assignment: * Log in to the [Corppass Portal](https://www.corppass.gov.sg/). * Check if you are explicitly authorised for the specific Myinfo Business digital service, or if you have access to all digital services. * If not, contact your Corppass Administrator. Refer to the [instruction guide](https://portal.singpass.gov.sg/home/ui/support) or [FAQ](https://ask.gov.sg/singpass/questions/clul27aq60028yisxifw2l2w3?from=quicklinks) on how to register for a Singpass account. Refer to the [FAQ on Corppass access](https://ask.gov.sg/corppass/questions/cm1q0y3r8008pwdnws9oepc2f) for Corppass-related questions.
### Viewing and Updating Data
What should I do if Myinfo Business data is outdated? Users should be allowed to manually correct data in the form on the digital service. Users are also encouraged to update their details with the relevant government agencies to keep their records current.
How do I view or update my entity details? Myinfo Business retrieves official data that your businesses have lodged with the Government. To view or amend your data, please contact the relevant source agencies: * ACRA data: [Access BizFile](https://www.bizfile.gov.sg/ngbbizfileinternet/faces/oracle/webcenter/portalapp/pages/eServicesListing.jspx?transId=B&_afrLoop=50971513237406072&_afrWindowMode=0&_afrWindowId=fqc22d4dj&_adf.ctrl-state=aubs3iwyg_26#!%40%40%3F_afrWindowId%3Dfqc22d4dj%26_afrLoop%3D50971513237406072%26transId%3DB%26_afrWindowMode%3D0%26_adf.ctrl-state%3Daubs3iwyg_30). * BGP data: [Leave feedback here](https://www.businessgrants.gov.sg/feedback). * BCA data: [Access eBACS](https://www.bca.gov.sg/eBACS/Document/eBACS_User_Guide.pdf). * Corppass data: [Update contact information](https://www.corppass.gov.sg/corppass/common/userguides).
How do I view or update my personal details? These data are official records retrieved from government sources and reflect what has been registered with the government. If any information is incorrect, please contact the relevant agency (e.g., ICA) to update the respective data. It normally takes **1-3 working days** for your Myinfo profile to reflect the updated data after verification by the agency.
Can I retrieve personal data of other directors in my business? No. For privacy reasons, you can only access your business’ corporate data and your own personal data via Myinfo Business.
*** ### Contact Us For additional queries, entity users may access support via the [Corppass Contact page](https://www.corppass.gov.sg/corppass/common/contactus). # Corppass Authorization API (FAPI 2.0) {% hint style="info" %} **Integrate with FAPI 2.0 for Enhanced Security** FAPI 2.0 is a high-assurance security profile built on OAuth 2.0 and OpenID Connect, that strengthens authentication and authorisation. \ **What this means for partners integrating with Corppass Login** * New services must use FAPI 2.0 to meet the latest security standards. * All existing services onboarded before 23 March 2026 must migrate to FAPI 2.0 by 31 March 2027, as the legacy security profile will be deprecated on 1 April 2027. To ensure continuity of service, we encourage planning and completing migration early. [Refer to migration guide](/technical-specifications/corppass-authorization-api-fapi-2.0/migration-guides/migration-guide-legacy-to-fapi-2.0) * Submit your migration plan (current progress and target date) so we can support your transition and avoid service disruption. [Submit migration plan](https://go.gov.sg/cp-fapi-migration-plan) \ **What this means for partners integrating with Myinfo Business** * Myinfo Business (v3) is now available for onboarding. [Refer to getting started guide](/products/myinfo-business/getting-started) * All existing applications (v1/v2) must migrate to Myinfo Business v3 by 31 May 2027, as legacy versions will be deprecated after this date. To ensure continuity of service, we encourage planning and completing your migration early. [Refer to migration guide](/technical-specifications/corppass-authorization-api-fapi-2.0/migration-guides/migration-guide-myinfo-business-v1-v2-to-v3-fapi-2.0) {% endhint %} ## Introduction This technical specification describes the **web-based Application Programming Interfaces (APIs)** provided by *Corppass* for use by *Relying Parties (RPs)*. It defines the required endpoints and interactions to: * Initiate user authentication using the **OpenID Connect (OIDC)** protocol * Securely and reliably retrieve **identity** and **authorization information** Corppass implements the **OpenID Foundation’s Financial-grade API (FAPI) 2.0 Security Profile**, a high-assurance security standard built on top of OAuth 2.0 and OpenID Connect. This ensures that all authentication and authorization flows are protected using: * **JWE-encrypted ID tokens** * **JWT-based client authentication** (client assertions) * **Sender-constrained access tokens via DPoP** (Demonstration of Proof of Possession) ## Getting Started Follow the [Integration Guide](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide) for step-by-step instructions on registering your application and implementing the secure authorization flow. For existing partners moving from the Legacy Security Profile, please refer to the [Migration Guide](/technical-specifications/corppass-authorization-api-fapi-2.0/migration-guides/migration-guide-legacy-to-fapi-2.0) for specific transition steps. # Integration Guide This guide outlines the steps to integrate with Corppass Authorization API. ## Environments Corppass provides separate environments for integration and testing (Staging) and live transactions (Production). Use the **Base URL** corresponding to the selected environment for all subsequent steps. **Recommendation:** It is recommended to integrate and validate implementation against the Staging environment before switching to Production.
EnvironmentBase URLDescription
Staginghttps://stg-id.corppass.gov.sgUsed for development, integration testing, and pre-production validation.
Productionhttps://id.corppass.gov.sgLive environment for real users and transactions. Must be used only after successful onboarding and certification.
## Steps {% hint style="info" %} #### Prerequisite: Client Application Registration Before starting integration, create and configure your client application. * **Corppass Login application**: Use the **Corppass Developer Portal (CDP)** to create your client application and obtain your Client ID. [Refer to getting started](/products/corppass-login/getting-started) * **Myinfo Business application:** Use the Singpass Developer Portal (SDP) to create your client application and obtain your Client ID. [Refer to getting started](/products/myinfo-business/getting-started) {% endhint %} {% hint style="info" %} #### Implementation Notes * **Certified Libraries:** As Corppass Authorization API is fully compliant with OIDC and FAPI 2.0, it is highly recommended to use a [Certified OIDC Relying Party Library](https://openid.net/developers/certified-openid-connect-implementations/). This simplifies development and ensures compliance.\ If you opt to implement the protocol directly, we encourage you to validate your implementation using the [OIDC Conformance Tests](https://openid.net/certification/fapi_rp_testing/). * **Dynamic Discovery:** Do not hardcode endpoint paths (e.g., `/token`). Always derive them from the Base URL using the [Discovery Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/0.-well-known-endpoints/openid-discovery-endpoint). * **TLS Certificates:** Do not implement certificate pinning nor have any dependencies on the TLS certifications for Corppass domains. **Corppass reserves the right to update or rotate its TLS certificates without prior notice.** {% endhint %} ### Overview The following diagram illustrates the FAPI 2.0 Authorization Code Flow. This flow requires a Confidential Client (Backend-for-Frontend) architecture. * RP Client (FE): The browser / frontend handles user interaction and redirects. * RP Server (BE): The backend maintains the secure session. All sensitive operations - including signing requests, handling DPoP keys, and token exchange - must occur on the backend to prevent credential leakage.
### 0. Configuration & Discovery **Endpoint:** `/.well-known/openid-configuration` | [View Specification](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/0.-well-known-endpoints) **Access:** Public TLS Once registered, programmatically discover Corppass's current configuration at runtime. * **Fetch Metadata (Discovery Endpoint):** Initiate a request to the [OpenID Discovery Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/0.-well-known-endpoints/openid-discovery-endpoint) to retrieve the provider configuration. This provides endpoint URLs, supported scopes, algorithms, and JWKS locations needed for the authorization flow. * **Fetch Public Keys (JWKS Endpoint):** Using the `jwks_uri` found in the metadata, fetch and cache Corppass's public keys. These are required later to verify the signatures of the ID Token and UserInfo response. ### 1. Secured Request - Pushed Authorization Request (PAR) **Endpoint:** `/request` | [View Specification](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/1.-pushed-authorization-request-par-endpoint) **Access:** Public TLS with Client Assertion and DPoP **Trigger:** Initiate this flow immediately when the user initiates login with Corppass. Corppass FAPI 2.0 requires the Pushed Authorization Request (PAR) flow. Authorization parameters are "pushed" securely via a back-channel API call rather than being exposed in the browser URL. * **Action:** Send a `POST` request to the PAR endpoint. * **Result:** The response contains a short-lived **`request_uri`**, which is required for the subsequent Authorization Endpoint step. ### 2. User Authentication - Authorization Endpoint **Endpoint:** `/authorize` | [View Specification](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/2.-authorization-endpoint) **Access:** Public TLS (Browser Redirect) Once the request payload is registered via PAR, redirect the user's browser to Corppass to perform the actual Singpass login and consent. * **Action:** Redirect the user to the Authorization Endpoint with the `request_uri` obtained from PAR. * **Result:** After successful authentication, the user agent is redirected to the client's redirect URI with an **Authorization Code**, which is required for the subsequent Token Exchange step. ### 3. Token Exchange - Token Endpoint **Endpoint:** `/token` | [View Specification](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/3.-token-endpoint) **Access:** Public TLS with Client Assertion and DPoP This is a secure back-channel exchange where the Authorization Code is swapped for actual credentials (Tokens). * **Action:** Send a `POST` request to the Token Endpoint, with the Authorization Code obtained from the authorization request. * **Result:** The response contains: * **ID Token:** A signed and encrypted JWE that includes the entity and user information. Relying Parties (RPs) must decrypt it using their private encryption key, then verify the JWT's signature using Corppass' public keys, available at the Corppass JWKS endpoint. * **Access Token:** A signed JWS intended for the Corppass resource server(s). This sender-constrained token is required to query the UserInfo Endpoint for additional data. ### 4. Fetch Additional Data - Userinfo Endpoint **Endpoint:** `/userinfo` | [View Specification](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint) **Access:** Public TLS with Access Token and DPoP If the application requires additional entity or user information - that is not present in the ID Token, query the UserInfo endpoint. * **Action:** Send a `GET` request to the Userinfo endpoint, with the Access Token obtained from the Token Endpoint. * **Result:** The response contains information based on the requested scopes, where applicable. * Authorization details for the authenticated user * Personal information for the authenticated user * Entity information for the transacting entity # 0. Well-known Endpoints Corppass supports industry-standard **OpenID Connect (OIDC) Discovery** mechanisms. These publicly accessible endpoints allow Relying Parties (RPs) to programmatically discover Corppass' current configuration, endpoint locations, and cryptographic keys. By utilizing these endpoints, your application can configure itself dynamically, reducing the risk of hardcoded errors and ensuring resilience against infrastructure changes. #### Why use these endpoints? * **Dynamic Configuration:** Automatically updates endpoint URLs if Corppass infrastructure changes. * **Zero-Downtime Key Rotation:** Automatically fetches new keys when Corppass rotates signatures, preventing service outages. * **Standard Compliance:** Ensures seamless integration with standard OIDC client libraries. *** ### Integration Workflow To integrate successfully, your application should implement the following logic to "bootstrap" its configuration at startup and handle key rotation at runtime. #### Step 1: Fetch Provider Metadata When: Application Startup * Initiate a `GET` request to the OpenID Discovery Endpoint. * This returns a JSON document containing critical configuration data, including the locations of the Authorization, Token, and JWKS endpoints. * Refer to [OpenID Discovery Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/0.-well-known-endpoints/openid-discovery-endpoint) for more details. #### Step 2: Extract & Configure When: Immediately after Step 1 * Parse the JSON response. * Configure Endpoints: Update your OIDC client with the dynamic URLs (e.g., for `pushed_authorization_request_endpoint`, `authorization_endpoint`, and `token_endpoint`). * Locate Keys: Extract the `jwks_uri` field. This URL is required for the next step. #### Step 3: Fetch & Cache Public Keys When: Application Startup (and periodically) * Initiate a `GET` request to the URL found in `jwks_uri`. * Cache Strategy: Store the retrieved JSON Web Key Set (JWKS) in a local cache (e.g., Redis or memory). * TTL (Time-To-Live): Set a reasonable expiration (e.g., 1 hour) to balance performance with freshness. * Refer to [JWKS Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/0.-well-known-endpoints/jwks-endpoint) for more details. #### Step 4: Handle Key Rotation (Runtime) When: Token Verification Fails * If your application receives a token with a Key ID (`kid`) that is missing from your local cache: 1. Do not reject immediately. 2. Force Refresh: Trigger an immediate request to the `jwks_uri` to fetch the latest keys. 3. Retry Verification: Attempt to verify the token signature again with the updated key set. 4. Reject: If the key is still missing after the refresh, reject the request. *** {% content-ref url="/pages/IwZgaFw7FMqg56MsCuSh" %} [OpenID Discovery Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/0.-well-known-endpoints/openid-discovery-endpoint) {% endcontent-ref %} {% content-ref url="/pages/AYiVcdjCesILoJyr9nXE" %} [JWKS Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/0.-well-known-endpoints/jwks-endpoint) {% endcontent-ref %} # OpenID Discovery Endpoint The **OpenID Discovery Endpoint** provides essential metadata about OpenID Provider (OP) - in this case, Corppass - configuration. This JSON document allows Relying Parties (RPs) to dynamically configure their interactions, ensuring they always use the correct endpoints, cryptographic algorithms, and supported features. ## Request ```http GET /.well-known/openid-configuration ``` ## Response The response is a JSON object containing the OpenID Provider (OP) metadata. {% hint style="info" %} **Performance Note: Caching** Responses from the OpenID Discovery Endpoint should be cached for at least 1 hour to minimize repeated requests during OIDC / OAuth2 operations. {% endhint %}
FieldTypeDescription
issuerStringThe URL identifying the OpenID Provider (OP) as the issuer of tokens. Defined in RFC 7519, Section 4.1.1.
jwks_uriStringThe URL of the OP's JSON Web Key Set (JWKS) endpoint. Clients use this endpoint to retrieve public keys for validating token signatures. Refer to RFC 7517, Section 4.
scopes_supportedArrayJSON array listing the OAuth 2.0 scope values that the OP supports, such as openid, which is mandatory for OpenID Connect flows.
claims_supportedArrayJSON array containing a list of Claim Names the OP may supply in tokens or the UserInfo response. Defined in OpenID Connect Core 1.0, Section 5.1.
claim_types_supportedArrayJSON array listing the Claim Types supported by the OP, such as normal, aggregated, or distributed. Defined in OpenID Connect Core 1.0, Section 5.6.
claims_parameter_supportedBooleanBoolean value indicating whether the OP supports the claims parameter to request specific claims. If omitted, the default value is false. Refer to OpenID Connect Core 1.0, Section 5.5.
subject_types_supportedArrayJSON array containing a list of Subject Identifier types that the OP supports, such as public or pairwise. Refer to OpenID Connect Core 1.0, Section 8.
code_challenge_methods_supportedArrayJSON array listing the Proof Key for Code Exchange (PKCE) code_challenge methods supported by the OP, such as S256. Defined in RFC 7636, Section 4.3.
grant_types_supportedArrayJSON array listing the OAuth 2.0 grant_type values supported by the OP, such as authorization_code or refresh_token. Refer to RFC 6749, Section 4.
request_parameter_supportedBooleanBoolean indicating whether the OP supports the request parameter for JWT-based requests. Default is false if omitted.
request_uri_parameter_supportedBooleanBoolean indicating whether the OP supports the request_uri parameter. Default is true if omitted.
response_types_supportedArrayJSON array containing a list of OAuth 2.0 response_type values that the OP supports. Defined in OAuth 2.0 Multiple Response Type Encoding Practices.
response_modes_supportedArrayJSON array listing OAuth 2.0 response_mode values supported by the OP, such as query or fragment. Defined in OAuth 2.0 Multiple Response Type Encoding Practices.
authorization_endpointStringThe URL of the OP's OAuth 2.0 Authorization Endpoint, where users authenticate and provide consent. Refer to OpenID Connect Core 1.0, Section 3.1.2.
authorization_response_iss_parameter_supportedBooleanBoolean indicating whether the OP includes the iss parameter in the authorization response. This is set to true. If you are using an OpenID/OAuth2 client, this instructs the library to expect and validate the iss parameter in the authorization responses.
token_endpointStringThe URL of the OP's OAuth 2.0 Token Endpoint. Clients exchange an authorization code for tokens at this endpoint.
token_endpoint_auth_methods_supportedArrayJSON array listing the client authentication methods supported by the Token Endpoint, such as private_key_jwt. Refer to OpenID Connect Core 1.0, Section 9.
token_endpoint_auth_signing_alg_values_supportedArrayJSON array listing the JWS signing algorithms (alg values) supported by the Token Endpoint for JWT authentication. Refer to RFC 7518, Section 3.1.
id_token_signing_alg_values_supportedArrayJSON array listing the JWS signing algorithms (alg values) supported by the OP for signing ID Tokens. Defined in RFC 7518, Section 3.1.
id_token_encryption_alg_values_supportedArrayJSON array listing the JWE encryption algorithms (alg values) supported by the OP for encrypting ID Tokens. Defined in RFC 7516, Section 4.1.1.
id_token_encryption_enc_values_supportedArrayJSON array listing the JWE encryption algorithms (enc values) supported by the OP for encrypting ID Tokens. Defined in RFC 7516, Section 4.1.2.
userinfo_endpointStringThe URL of the OP's UserInfo Endpoint, used to retrieve claims about the authenticated user. Defined in OpenID Connect Core 1.0, Section 5.3.
userinfo_signing_alg_values_supportedArrayJSON array listing JWS signing algorithms (alg values) supported by the UserInfo Endpoint for encoding claims in a JWT. Defined in RFC 7515, Section 4.
userinfo_encryption_alg_values_supportedArrayJSON array listing JWE encryption algorithms (alg values) supported by the UserInfo Endpoint for encrypting claims in a JWT. Defined in RFC 7516, Section 4.1.1.
userinfo_encryption_enc_values_supportedArrayJSON array listing JWE encryption algorithms (enc values) supported by the UserInfo Endpoint for encrypting claims in a JWT. Defined in RFC 7516, Section 4.1.2.
userinfo_signing_alg_values_supportedArrayJSON array listing JWS signing algorithms (alg values) supported by the UserInfo Endpoint for encoding claims in a JWT. Defined in RFC 7515, Section 4.
### Sample Response ```http HTTP/2 200 content-type: application/json; charset=utf-8 content-length: 1667   { "name": "corppass", "issuer": "https://id.corppass.gov.sg", "jwks_uri": "https://id.corppass.gov.sg/.well-known/keys", "scopes_supported": [...], "claims_supported": [...], "claim_types_supported": [...], "claims_parameter_supported": false, "subject_types_supported": [...], "code_challenge_methods_supported": [...], "grant_types_supported": [...], "request_parameter_supported": false, "request_uri_parameter_supported": false, "response_types_supported": [...], "response_modes_supported": [...], "pushed_authorization_request_endpoint": "https://id.corppass.gov.sg/request", "authorization_endpoint": "https://id.corppass.gov.sg/mga/sps/oauth/oauth20/authorize", "authorization_response_iss_parameter_supported": true, "token_endpoint": "https://id.corppass.gov.sg/mga/sps/oauth/oauth20/token", "token_endpoint_auth_methods_supported": [...], "token_endpoint_auth_signing_alg_values_supported": [...], "id_token_signing_alg_values_supported": [...], "id_token_encryption_alg_values_supported": [...], "id_token_encryption_enc_values_supported": [...], "userinfo_endpoint": "https://id.corppass.gov.sg/userinfo", "userinfo_signing_alg_values_supported": [...], "userinfo_encryption_alg_values_supported": [...], "userinfo_encryption_enc_values_supported": [...] } ``` # JWKS Endpoint The **JSON Web Key Set (JWKS) Endpoint** hosts the **Public Signing Keys** used by Corppass. Corppass signs all sensitive tokens (including the ID Token and Userinfo Response) using a dedicated private key. To validate the integrity and authenticity of these tokens, Relying Parties (RPs) must retrieve the corresponding public key from this endpoint. ## Request Dynamically obtain this URL from the [OpenID Discovery Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/0.-well-known-endpoints/openid-discovery-endpoint) (`jwks_uri`). ```http GET /.well-known/keys ``` ## Response The response is a JSON object containing an array of keys (`keys`). Each key follows the JSON Web Key (JWK) specification. {% hint style="info" %} **Performance Note: Caching** Responses from this endpoint, or individual keys within the JWKS, should be cached by the RP for at least 1 hour to avoid retrieving the JWKS for every JWT validation. {% endhint %} ### Sample Reponse ```http HTTP/2 200 content-type: application/jwk-set+json; charset=utf-8 content-length: 955 { "keys": [ { "kty": "EC", "use": "sig", "kid": "OvNklZwNmhiE6tu9mtWTDAv218k2DMjuRaGhkBgFdOo", "alg": "ES256", "crv": "P-256", "x": "gnbm-h8k3ZzeegHK0x87wO_SP_MLFts9XPZm7pE8U04", "y": "JvtZtPUqAS6837asiImtx-oO05wQS-Z6lOneq9zi_qQ", } ] } ``` ## How to Validate a Signature This endpoint returns one or more public keys in JSON Web Key (JWK) format. To validate a JWT signature, your application (or OIDC library) must follow these steps: 1. **Extract Header:** Parse the JOSE Header of the received JWT (ID Token or Userinfo). 2. **Read Key ID:** Note the `kid` (Key ID) value in that header. 3. **Find Key:** Look up the key in the JWKS response where the `kid` matches the token's `kid`. 4. **Check Usage:** Ensure the matched key has the attribute `"use": "sig"` (that indicates a signing key). 5. **Verify:** Use this public key to verify the JWT signature. ## Key Rotation Corppass reserves the right to rotate / update its signing keys at any time, and without prior notice. **When a key rotation occurs:** 1. New keys will be published to the JWKS endpoint, each with a unique `kid` value. 2. JWTs issued after the rotation will reference the updated `kid` in their JOSE headers. 3. RPs must refresh their cached JWKS by querying the JWKS endpoint to retrieve the updated keys. **Handling Rotation (Best Practice):** To ensure zero downtime, RPs should implement a "Lazy Refresh" strategy: 1. **Cache** the JWKS response locally (e.g., for 1 hour). 2. **Check:** When verifying a token, check if the `kid` exists in your cache. 3. **Refresh:** If you receive a token with an unknown `kid`, immediately refresh your cache by calling this endpoint again. 4. **Retry:** Attempt validation again with the newly fetched keys. # 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](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/supported-tls-cipher-suites) for the full list. ## Request To initiate the flow, send a `POST` request to the PAR Endpoint URL obtained from the [OpenID Discovery Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/0.-well-known-endpoints/openid-discovery-endpoint) (`pushed_authorization_request_endpoint`). ```http POST /request ``` ### Request Headers
HeaderRequiredDescription
Content-TypeYes

Indicates the encoding format of the request body.

Validation:

  • Must be set to application/x-www-form-urlencoded.
DPoPYes

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
FieldRequiredDescription
client_idYesThe unique identifier assigned to the Relying Party application during onboarding.
client_assertionYes

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_typeYes

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_challengeYes

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_methodYes

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_typeYes

Indicates the authorization flow to be executed.

Validation:

  • Must be set to code, as mandated by FAPI 2.0 specifications.
redirect_uriYes

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.
scopeYes

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.

stateYes

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.
nonceYes

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_valuesNo

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_typeYes

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_messageNo

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_jktNo

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
FieldTypeDescription
request_uriString

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_inNumber

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
FieldTypeDescription
errorString

A standardised error code identifying the type of error that occurred.


See Error Codes below for a complete list of possible values.

error_descriptionStringA human-readable text description providing additional details about the error.
stateStringThe opaque value originally provided by the client in the request body, returned unmodified.
#### Error Codes
Error CodeHTTP StatusError Description
invalid_request400

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_client400 / 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_scope400The requested scope is invalid, unknown, malformed, or exceeds the scope granted to the client.
invalid_dpop_proof401

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_error500The authorization server encountered an unexpected internal error while processing the request.
temporarily_unavailable503The 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**](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/2.-authorization-endpoint) **to redirect the user and obtain the Authorization Code.** # Authentication Context Parameters New parameters have been introduced in the authorization flow to help contextualise each authorization request via [Pushed Authorization Request](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/1.-pushed-authorization-request-par-endpoint). These parameters are not part of the standard OpenID Connect (OIDC) specification and are specific to the [Corppass Login](/products/corppass-login).
FieldRequiredDescription
authentication_context_typeYes

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.

The list of supported values is provided below.

authentication_context_messageNo

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.
### Supported authentication\_context\_type values Currently, Corppass only supports one possible value:
Eventauthentication_context_type Value
General authenticationAPP_AUTHENTICATION_DEFAULT
Additional values may be added in the future as new use cases arise. ### Guidance on `authentication_context_type` usage * If none of the predefined use cases above accurately describe your transaction, use the default value `APP_AUTHENTICATION_DEFAULT` for the general authentication use case. * For general authentication to an e-service that performs a variety of actions, use the default value: `APP_AUTHENTICATION_DEFAULT`. This is expected to cover the majority of e-services. * For more sensitive or transaction-specific actions that require step-up verification, a more specific `authentication_context_type` should be used. # 2. Authorization Endpoint The **Authorization Endpoint** is the entry point for the user's authentication journey. After successfully registering the request parameters via the [Pushed Authorization Request (PAR) endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/1.-pushed-authorization-request-par-endpoint), the user's browser must be redirected to this endpoint to authenticate with Corppass. ## Request (Redirect the User) To initiate the authentication session, redirect the user's browser to the Authorization Endpoint URL obtained from the [OpenID Discovery Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/0.-well-known-endpoints/openid-discovery-endpoint) (`authorization_endpoint`). ```http GET /mga/sps/oauth/oauth20/authorize  ``` ### Query Parameters Unlike legacy flows, this request does *not* contain sensitive parameters (such as `scope` or `redirect_uri`) in the query string. Instead, it utilises the `request_uri` obtained from the PAR response to reference the pre-validated payload.
ParameterRequiredDescription
client_idYes

The unique identifier assigned to the Relying Party application during onboarding.

Validation:

  • Must strictly match the client_id used in the preceding Pushed Authorization Request (PAR).
request_uriYes

The unique Uniform Resource Identifier (URI) that references the authorization parameters stored during the PAR step.

Validation:

  • Must be the exact request_uri value returned in the response from the PAR Endpoint.
  • This URI is short-lived. The client must redirect the user to the Authorization Endpoint before the URI expires (within 60 seconds).
### Sample Request (Redirect URL) {% code overflow="wrap" %} ```http GET /mga/sps/oauth/oauth20/authorize ?client_id=51YUlwazLASM7aqMiBNW &request_uri=urn:ietf:params:oauth:request_uri:h8YQPVV0Dgm5MGaD_koAm HTTP/1.1 Host: id.corppass.gov.sg ``` {% endcode %} ## Success Response (Callback) Upon successful authentication, the user agent is redirected to the `redirect_uri` registered in the PAR step via a `302 Found` response. The following paramters are appended to the query string. ### Query Parameters
ParameterDescription
code

Authorization Code. A short-lived, single-use credential required to retrieve Access Token and ID Token at the Token Endpoint.


The code is valid for 60 seconds and can only be used once.

state

The opaque value originally provided by the client in the authorization request (PAR), returned unmodified. This is to mitigate Cross-Site Request Forgery (CSRF, XSRF) attacks.

Validation:

  • The Relying Party must verify that this value strictly matches the state stored in the user's session from the initial request (PAR).
  • If the values do not match, the response is invalid and likely part of a Cross-Site Request Forgery (CSRF) attack. Reject the request immediately.
issThe issuer identifier of the Corppass authorization server (See the issuer field in the OpenID Discovery Endpoint). Both success and failure response redirects will contain this parameter. For security, it is recommended that clients verify this value against the expected Corppass issuer before acting on the response. If you are using an OpenID/OAuth2 client, this will be validated by the library for you.
{% hint style="warning" %} **It is strongly recommended** to use a [certified OIDC Relying Party library](https://openid.net/developers/certified-openid-connect-implementations/), as the standard checks are automatically handled by the library. {% endhint %} ### Sample Reponse (Callback URL) ```http HTTP/1.1 302 Found Location: https://client.example.org/callback ?code=KxygiAyIIHu4OCCqjF9XAxpCjKk0uUkKNA6mfVD9HZw &state=5de6a954-a762-4975-a8f4-b692cc35b964 &iss=https%3A%2F%2Fid.corppass.gov.sg ``` ## Error Response (Callback) If authentication fails, is denied by the user, or a processing error occurs, the user agent is redirected to the `redirect_uri` (provided in the PAR step), where applicable, with the following error parameters appended to the query string. {% hint style="warning" %} Clients **must** handle the error parameters to provide appropriate feedback or guidance to the user, to ensure smooth user experience. {% endhint %} ### Query Parameters
Query ParameterDescription
error

A standardised error code identifying the type of error that occurred.


See Error Codes below for a complete list of possible values.

error_descriptionA human-readable text description providing additional details about the error.
state

The opaque value originally provided by the client in the authorization request (PAR), returned unmodified if available.

Validation:

  • Used to correlate the error response with the correct user session.
issThe issuer identifier of the Corppass authorization server (See the issuer field in the OpenID Discovery Endpoint). Both success and failure response redirects will contain this parameter. For security, it is recommended that clients verify this value against the expected Corppass issuer before acting on the response.
#### Error Codes
Error CodeDescription
login_requiredThe user does not have an active session, the session has expired, or the session has been invalidated.
access_deniedThe resource owner or authorization server denied the request.
server_errorThe authorization server encountered an unexpected internal error while processing the request.
The error can potentially be due to the RP’s JWK endpoint being unreachable or returning a malformed JWK.
temporarily_unavailableThe server is temporarily unable to handle the request due to maintenance or high load.
### Sample Response (Callback URL) 
HTTP/1.1 302 Found
Location: https://client.example.org/callback
?error=server_error
&error_description=The+server+encountered+an+unexpected+internal+error+while+processing+the+request.
&state=Zw_r_a2uBDoy-kR7562RjM4-C9K3C2zDRQg-AJsDwb4
&iss=https%3A%2F%2Fid.corppass.gov.sg
## Next Steps **Exchange the Code for Tokens:** Once the Authorization Code is received, exchange it for the Access Token and ID Token via a secure back-channel call. **Proceed to** [**3. Token Endpoint**](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/3.-token-endpoint) **to perform the token exchange.** # 3. Token Endpoint The **Token Endpoint** is used by the client to exchange an authorization code for tokens after the user successfully authenticates. This is a *secure back-channel request* made directly between the client and Corppass. #### Returned Tokens * **ID Token:** A signed and encrypted JWE that includes the entity and user information. Relying Parties (RPs) must decrypt it using their private encryption key, then verify the JWT's signature using Corppass' public keys, available at the Corppass JWKS endpoint. * **Access Token:** A signed JWS intended for the Corppass resource server(s). #### Supported Grant Types Grant types define the method by which a client obtains tokens from the authorization server. For the Open ID Connect (OIDC) authentication flow, Corppass supports the following grant types:
Grant TypeDescription
authorization_code

Used to securely exchange an authorization code for an ID token and Access Token. Requires prior user authentication and is suitable for confidential clients.

Refer to Section 3.1 of the OIDC Core Specification for more details.

#### Supported TLS Cipher Suites Please ensure you are using a supported cipher suite for this endpoint. Refer to [Supported TLS Cipher Suites](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/supported-tls-cipher-suites) for the full list. ## Request To obtain the Access Token and ID Token, send a `POST` request to the Token Endpoint URL obtained from the [OpenID Discovery Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/0.-well-known-endpoints/openid-discovery-endpoint) (`token_endpoint`). ```http POST /mga/sps/oauth/oauth20/token ``` ### Request Headers
FieldRequiredDescription
Content-TypeYes

Indicates the encoding format of the request body.

Validation:

  • Must be set to application/x-www-form-urlencoded.
DPoPYes

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:

  • Must be signed using the exact same private key as the DPoP proof presented in the Pushed Authorization Request (PAR) step.

Refer to Demonstrating Proof of Possession section for more details.

### Request Body
FieldRequiredDescription
codeYes

Authorization Code. The authorization code issued during the callback step at Authorization Endpoint.

Validation:

  • The code is valid for 60 seconds. Expired codes will result in an error.
  • The code can only be exchanged once.
redirect_uriYes

The absolute URI used in the initial authorization request (PAR).

Validation:

  • Must strictly match the redirect_uri provided in the original Pushed Authorization Request (PAR).
grant_typeYes

The type of authorization grant being requested.

Validation:

  • Must be set to authorization_code.
client_idNo

Optional. The unique identifier assigned to the Relying Party during onboarding.

Validation:

  • If provided, this value must match the sub (subject) claim in the Client Assertion JWT.
client_assertion_typeYes

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.
client_assertionYes

A signed JWT used to authenticate 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.

code_verifierYes

PKCE Verifier. The cryptographically random string generated by the client to prove possession of the code_challenge.

Validation:

  • Must be the original plain-text value used to generate the code_challenge provided at PAR.

Refer to Proof Key of Code Exchange section for more details.

### Sample Request ```http POST /mga/sps/oauth/oauth20/token Content-Type: application/x-www-form-urlencoded DPoP: grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &client_id=51YUlwazLASM7aqMiBNW &client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer &client_assertion=eyJ... &code_verifier=hJ1GZ4ekBQ-NNlc4t62KsLqWhM6p1ZpwRc1cwFtoLp ``` ## Success Response If the request is valid, Corppass returns a JSON response containing the tokens. ### Response Body
FieldTypeDescription
token_typeString

Indicates the type of access token issued.

Value is always set to DPoP.

access_tokenJWS

Access Token. A signed JSON Web Signature (JWS) used to access protected resources (e.g., Userinfo Endpoint).


The token is valid for 10 minutes from time of issuance.

Refer to Access Token section for more details.

id_tokenJWE

ID Token. A signed and encrypted JSON Web Encryption (JWE) containing user and entity identities, and authentication claims.


Processing:

  • The RP must decrypt this token using their Private Encryption Key.
  • After decryption, the inner JWT signature must be verified using Corppass' public keys.

Refer to ID Token section for more details.

scopeString

Granted Scopes. A space-delimited list of scopes actually granted to the Access Token.

This list typically matches the scopes requested during authorization, though the server may grant a subset of requested scopes based on user consent or policy.

expires_inNumeric

The remaining lifetime of the Access Token in seconds.

Value is set to 600 seconds.

### Sample Response ```json { "token_type": "DPoP", "access_token": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6InhHbkJ4ZVYtWTFubUJlZi1KXzBTSWNxaU1hR2NlYWJzaVkxZjRJUkMya0kifQ.eyJmYXBpX2Zsb3ciOnRydWUsImFjdCI6eyJzdWIiOiJhOTg2NTgzNy03YmQ3LTQ2YWMtYmVmNC00MmE3NmE5NDY0MjQifSwiY25mIjp7ImprdCI6ImJvWVZEeFhTN1l6bF9yNFAyVnNvY2E5Ujkyd2dUSEdya25zZy13b2F2dnMifSwianRpIjoiV19YTmZQZGNaelIzMUl2aTFLVEJ2Iiwic3ViIjoiMTIwNjc0ODRaIiwiaWF0IjoxNzc2NDA3NDM3LCJleHAiOjE3NzY0MDgwMzYsInNjb3BlIjoib3BlbmlkIGF1dGhpbmZvIHRwYXV0aGluZm8gdXNlci5pZGVudGl0eSB1c2VyLm5hbWUgZW50aXR5LmlkZW50aXR5IGVudGl0eS5iYXNpY19wcm9maWxlLm5hbWUgZW50aXR5LmJhc2ljX3Byb2ZpbGUudWVuX3N0YXR1cyIsImNsaWVudF9pZCI6Ill3bUFmWXNXSURpTWpIbmg5MUpFIiwiaXNzIjoiaHR0cDovL2xvY2FsaG9zdDozMDAwIiwiYXVkIjpbImh0dHA6Ly9sb2NhbGhvc3Q6MzAwMC91c2VyaW5mbyIsImh0dHA6Ly9sb2NhbGhvc3Q6MzAwMC9hdXRob3JpemF0aW9uLWluZm8iXX0.v8qy-z4D5joXl12HHNs68sLS848KE6tfXm1q2-b3uqRQ0JCbHkHOvGlsGEJ0r1glWtoFcAdXNtuSjMyEbkQ8WA", "id_token": "eyJhbGciOiJFQ0RILUVTK0EyNTZLVyIsImVuYyI6IkEyNTZDQkMtSFM1MTIiLCJjdHkiOiJKV1QiLCJraWQiOiJkZXYtZW5jIiwiaXNzIjoiaHR0cDovL2xvY2FsaG9zdDozMDAwIiwiYXVkIjoiWXdtQWZZc1dJRGlNakhuaDkxSkUiLCJlcGsiOnsieCI6Ik9VV3NDODJlQnNxYXN5cDFvbDJITmFhRHpOczlQaGpseUFJS0NnQUNCM1UiLCJjcnYiOiJQLTI1NiIsImt0eSI6IkVDIiwieSI6IkJRVDNFZndDQ1llT2JpMlhQN2tTRVk4TEU4QVB6dU85ZDhoOUJWb0Z2MkUifX0.fFbY2sGO4OfpRLZymADtH_TXiZulpK_GR_f2cfTz3-3NTzO1ig7NC1WXbqv4Adk_7-XEz5EQ51naqA2flu3p18c1JpADYekq.egEfNqL7ySZHD0fWfZJYVQ.qyoBjRfPjKGSCHpKLGUxGRuKhDYC1rW53xCnmxDQ8_gocc5BX0gfPjTB_8KAwDIxw8NrgMN91aLF-Rp-wR3qyvCa8aLkX9zCrDfAzMoD6BlNBqHh8dPah5RMe9P0xSFqbPnB2yU2CWNvG-yoCVLWJTsdpoBQ8w37AdCol1bq53emih2ghREt3x8MU1z_mk1UUVZkJYvXGuLr_GvJWoQa7A3ffkaOdXleiOMSu69M65VrYNnfl_RI-SE1x6cSmgSWeeao6PPw0NpitbMSdIkv3AGjLiMoWVWPAJd955k9-gvp_VjANzN38tumOx6jetLkIru-9HenIUDKfw1hZIaJDj-ZdFJHtrZoROig_4LQ62uvKkf_T8yhHsLCAffyO4kOBeGXYtAItdAtcP70vlMjISptOPrhofNSYWHUTo8v_rfOz7F4tG7H2fp3lNKN6vZPLGBeUpSvfgUFsVwbDfZH02NV852Dm9GoAphytgWLRR-Chic2xRUX2jiimqu28Zzf8o4dtWe93_qSKHBt1FgeIOr0zZMKkuzjRPzq5hEt4FgvprNTBy-LOMsULeTH6V25Ni7lfiyp2sqTk6aLdozfh2OQKau4-4hDpBPq-fUGSHAs95vpEr49MhGHNLk_D5RzVFI9IcOMVA8-iSVhERjhmVq6uvAe0l78c0hydRzj4GukTkBQYl3o3342WK98m0Wbl4-ftRsOpgY7H_QdGEbf1Wns18lSovqZyIDQGKikLgxxHGZGlqx1AxrLEswL_C25JRZvzsa3wNQJN465DDYoGHB3LWXHOy_Ndv5zRxYe53KR2KysMiOEBHY5PAu2iQ7FvGiY1-DQVx8_NkA0FGb0D7rT-yD2b75hC2udS3qLQzqklSg2Snf8-n4n9FUaUiyB9oUXMBiWIVQFwED_kIM2_121pfTN3cfgneqv1RpfZm1IdC2RkRiMEyi1Yb5IKj_Mb9IuMFXZhzqIlyhkIePZjQG3gW985ORSppgqjvSGYK93_yb9SZGpx65-RvFDVf-vyV-lfVo2E9UUzFFz6qba7ccviz1_iLLKDDfZe3-SV-VQt_QB4kglFKMyEN8CAZpAPzBsZSZpXgcCA1rvnoDRhjhf2UUMNtTlz7uiBZ5HUS9IzH_830lGGEdqH3KRj6_afY2iSSGDUYd0CrgMwIMghPxV146Yc_AsnJ2Wf7HuQb6GxlbUttLLvImUmnJhTAe8KscGTm6_k6AzN7GYw1fZirlHeG4jCC3_rLPm0rxmSSbIhvcZw-0MSrgq-j_oTapOAk2AeAU4cSKW5V_BeaW-dfXPTiBrv9pH6izY_6vnqX0.0OCnPEeCD5xOt_kPGTRqQypCKGjGdLmnNCOE50BNjGQ", "scope": "openid authinfo tpauthinfo user.identity user.name entity.identity entity.basic_profile.name entity.basic_profile.uen_status", "expires_in": 599 } ``` ## Error Response If the token exchange fails, Corppass returns a JSON response containing an error code and description. ### Response Body
FieldTypeDescription
errorString

A standardised error code identifying the type of error that occurred.


See Error Codes below for a complete list of possible values.

error_descriptionStringA human-readable text description providing additional details about the error.
#### Error Codes
Error CodeHTTP StatusDescription
invalid_request400 / 401

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.
  • The client’s JWKS endpoint is not reachable.
  • The JWKS object is empty or the encryption key is not available.
  • 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.
  • Your JWKS endpoint is accessible and returns a valid key set that complies with the required specification.
invalid_client400 / 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_grant400 / 401The provided authorization code is invalid, expired, revoked, or does not match the authenticated client.
invalid_dpop_proof401

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.
unsupported_grant_type400The grant type is not supported.
server_error500The authorization server encountered an unexpected internal error while processing the request.
temporarily_unavailable503The server is temporarily unable to handle the request due to maintenance or high load.
### Sample Response ```json { "error": "invalid_dpop_proof", "error_description": "DPoP proof iat is not recent enough" } ``` ## Next Steps #### 1. Retrieve Entity & User Identity (ID Token) The ID Token contains information about both the *Entity* and the *Acting User* performing the transaction. **Proceed to** [**ID Token**](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/3.-token-endpoint/id-token) **section for decryption steps and claim mapping.** #### 2. Fetch Additional Data (Userinfo Endpoint) If your application requires more detailed entity and user attributes not present in the ID Token, use the Access Token to query the Userinfo Endpoint for additional information. **Proceed to** [**4. Userinfo Endpoint**](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint) **to fetch additional data.** # ID Token The **ID Token** is a verifiable security token issued by Corppass after a successful authorization code exchange. It contains identity-related claims about the authenticated **Entity** and the **Acting User**. The ID Token is returned as a **JSON Web Encryption (JWE) object**, encrypted using the client's public encryption key configured in their JWKS object / JWKS endpoint. Inside the encrypted payload lies the **Signed JWT (JWS)**, signed using Corppass' private signing key. To securely access this information, you must process the token in *three sequential steps*: 1. **Decrypt** the outer JWE layer. 2. **Verify** the inner JWS signature. 3. **Validate before using** the JWT claims. ## 1. Outer Layer: JWE (Encryption) The outer JWE layer protects the confidentiality of the token. The payload is encrypted using the Client's Public Encryption Key (retrieved by Corppass from the Client's JWKS). It consists of *five dot-separated Base64URL-encoded parts*. 
<protected header>.<encrypted key>.<initialisation vector>.<ciphertext>.<authentication tag>
Refer to [JWS and JWE](/technical-specifications/technical-concepts/jws-and-jwe#json-web-encryption-jwe) section for more details. ### JWE Protected Header
FieldDescription
algKey Management Algorithm. The algorithm used to encrypt the key that encrypts the payload.
encContent encryption algorithm. The algorithm used to encrypt the payload.
typToken type. Always set to JWT.
kidKey ID. Identifies which Public Encryption Key from the RP's JWKS was used by Corppass to encrypt this token.
{% hint style="warning" %} Clients **must** use the **`kid`** field in the JWE header to identify which Private Encryption Key from their local keystore is required to decrypt the payload. {% endhint %} #### Sample JWE Header ```json { "alg": "ES256", "enc": "A256CGM", "typ": "JWT", "kid": "example-key-id" } ``` ### Action: Decrypt 1. Read the `kid` from the JWE header. 2. Look up the corresponding Private Encryption Key in your local keystore. 3. Decrypt the token using that private key. 4. The decrypted payload is a [Signed JWT (JWS)](#id-2.-inner-layer-jws-signature). ## 2. Inner Layer: JWS (Signature) After decrypting the JWE in Step 1, the resulting payload is a Signed JWT (JWS). This layer ensures the token was issued by Corppass and has not been tampered with. Refer to the [JWS and JWE](/technical-specifications/technical-concepts/jws-and-jwe#json-web-encryption-jwe) section for more details. ### JWT Header
FieldDescription
algSigning Algorithm. The algorithm used by Corppass to sign the token.
typToken type. Always set to JWT.
kidKey ID. Identifies the key used for signing.
#### Sample JWT Header ```json { "alg": "ES256", "typ": "JWT", "kid": "example-key-id" } ``` ### Action: Verify Signature 1. Read the `kid` from the JWS header. 2. Retrieve the matching Corppass Public Key from the [JWKS Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/0.-well-known-endpoints/jwks-endpoint). 3. Verify the signature of the JWS using that public key. 4. If the signature is valid, you can now trust the content. The payload is the [JWT Claims Set](#jwt-claims-payload). ## 3. JWT Claims (Payload) The decoded JSON payload from Step 2 contains the identity data, organized into three logical sections: **Metadata**, **Entity Identity**, and **Actor (Acting User) Identity**. ### Action: Validate 1. Validate the standard claims (`iss`, `aud`, `exp`, `nonce`) against your expected values. 1. `iss`: Must match the `issuer` URL in Corppass' [OpenID Discovery Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/0.-well-known-endpoints/openid-discovery-endpoint). 2. `aud`: Must match your assigned Client ID. 3. `exp`: Must be after current time (not expired). 4. `nonce`: Must match the `nonce` value sent in the initial Authorization Request. 2. Validate the `at_hash` to ensure the Access Token is bound to this ID Token. 1. `at_hash`: Must match the hashed value of the Access Token. {% hint style="warning" %} Before using this data, you **must validate the standard claims** to ensure the token is meant for you and is still valid. For clients using a [**certified OIDC Relying Party library**](https://openid.net/developers/certified-openid-connect-implementations/), these checks will be automatically performed by the library, though clients must still pass the nonce to the library for it to perform the nonce check. {% endhint %} ### A. Token Metadata
ClaimTypeDescription
issString

The issuer identifier of the Corppass authorization server.

Validation Required: Must Match: The issuer URL in Corppass' OpenID Discovery Endpoint.

audString

Audience. The client ID of your client application as registered during onboarding.

Validation Required: Must Match: Your assigned Client ID.

iatNumberIssued at. The unix timestamp, in seconds, at which the token was issued.
expNumber

Expiration time. The unix timestamp, in seconds, on or after which this token must not be accepted for processing.

Validation Required: Must Check: Current time < exp.

nonceString

Nonce. The string value used to associate a Client session with an ID Token, and to mitigate replay attacks. Matches the value sent in the authorization request.

Validation Required: Must Match: The nonce value sent in the initial Authorization Request.

amrString ArrayAuthentication methods references used during Singpass Login.

Refer to Supported AMR Values section for list of supported values.
at_hashString

Hash value of this access token.

Refer to Section 3.1.3.6 of OIDC Core 1.0 for more details.

Validation Required: Must Verify: Hash the Access Token and compare to this value. This validates the ID Token and Access Token's integrity, ensuring they have not been tampered with.

#### Supported `AMR` Values {% hint style="info" %} The list is non-exhaustive. Singpass reserves the right to introduce new values without prior notice. {% endhint %}
ValueDescription
pwdPassword
otp-smsSMS OTP
faceFace verification
face-altAlternative form of face verification.
swkSoftware-secured key (i.e. QR/shortcut login via Singpass app)
swk-passkeySoftware passkey
### B. Entity Identity (`sub`, `sub_attributes`) These claims identify the **Entity** that the user is transacting on behalf of. In Corppass, the primary `sub` of the token is *always* the Entity.
ClaimTypeDescription
subString

Subject identifier - the unique identifier of the entity. Represents the principal entity that is the subject of the JWT.

  • For UEN entity type, this is the UEN.
  • For Non-UEN entity type, this is the Corppass Entity ID.
sub_typeString

Subject type. Defines the type of the primary subject.

Always set to entity.

sub_attributesJSON

Primary subject information. Contains profile information about the subject (entity) identified by the sub claim.

Optional. Returned only if primary subject (entity) attributes are present - depending on the requested scopes.

Refer to sub_attributes Fields section below for more details.

#### `sub_attributes` Fields Contains information about the Subject (Entity) identified by the `sub` claim. {% hint style="info" %} This claim is only returned if it contains data (i.e., non-empty). The presence of specific fields depends on the scopes requested (e.g., `entity.identity`). {% endhint %}
ClaimTypeDescription
entity_typeString

The entity type.

Available values:

  • UEN
  • NON-UEN
  • GSTN

Required scope: entity.identity

entity_reg_numberString

Entity registration number.

Required scope: entity.identity

entity_coiString

Country of incorporation.

Two-letter country code (e.g., SG, MY).

Required scope: entity.identity

entity_nameString

The name of the registered entity.

Required scope: entity.basic_profile.name

entity_uen_statusString

The UEN entity status.
Returned only if the represented entity is of type UEN.

Available values:

  • Registered
  • Deregistered
  • Withdrawn

Required scope: entity.basic_profile.uen_status

#### Sample Entity Claims
Sample claims for a Singapore-registered Entity ```json { ... "sub": "T09LL0001B", "sub_type": "entity", "sub_attributes": { "entity_type": "UEN", "entity_reg_number": "T09LL0001B", "entity_coi": "SG", "entity_name": "My Example Company", "entity_uen_status": "Registered" } } ```
Sample claims for a Foreign Entity ```json { ... "sub": "C19001125A", "sub_type": "entity", "sub_attributes": { "entity_type": "NON-UEN", "entity_reg_number": "202219428Z", "entity_coi": "MY", "entity_name": "My Example Malaysian Company" } } ```
### C. Actor Identity (`act.sub`, `act.sub_attributes`) These claims identify the **Acting User** performing the transaction on behalf of the Entity.
ClaimTypeDescription
actJSON

Represents the actor acting on behalf of the primary subject identified by the sub claim.

In this case, this refers to the acting user performing the transaction on behalf of the entity.

Refer to act Fields section below for more details.

#### `act` Fields
ClaimTypeDescription
subString

Subject identifier. Represents the actor, which is the user acting on behalf of the primary entity subject.

This is the unique identifier of the user.

sub_typeString

Subject type. Defines the type of the actor subject.

Value: "user".

sub_attributesJSON

Actor subject information. Contains profile information about the subject (user) identified by the act.sub claim.

Optional. Returned only if actor subject (user) attributes are present - depending on the requested scopes.

Refer to act.sub_attributes Fields section below for more details.

#### `act.sub_attributes` Fields Contains information about the Subject (User) identified by the `act.sub` claim. {% hint style="info" %} This claim is only returned if it contains data (i.e., non-empty). The presence of specific fields depends on the scopes requested (e.g., `user.identity`). {% endhint %}
ClaimTypeDescription
account_typeString

The acting user's Singpass account type.

Available values:

  • standard - Singpass account holder (Singapore Citizen, PR, FIN holder)
  • foreign - Singpass Foreign Account holder

Required scope: user.identity

identity_numberString

The acting user's identity number.

  • account_type="standard" - NRIC or FIN number.
  • account_type="foreign" - Foreign ID number (e.g., Passport or National ID)

Required scope: user.identity

identity_coiString

Country of issuance of the acting user's identity.

Two-letter country code (e.g., SG, MY).

Required scope: user.identity

nameString

The acting user's full name.

Required scope: user.name

#### Sample Acting User Claims
Sample claims for an SC/PR / FIN user ```json { ... "act": { "sub": "1c0cee38-3a8f-4f8a-83bc-7a0e4c59d6a9", "sub_type": "user", "sub_attributes": { "account_type": "standard", "identity_number": "S1234567P", // NRIC / FIN "identity_coi": "SG", "name": "John Grisham" } } } ```
Sample claims for an SFA user 
{
  ...
  "act": {
    "sub": "1c0cee38-3a8f-4f8a-83bc-7a0e4c59d6a9",
    "sub_type": "user",
    "sub_attributes": {
      "account_type": "foreign",
      "identity_number": "K28394589", // Foreign ID
      "identity_coi": "MY",
      "name": "John Grisham"
    },
  }
}
### Sample Full JWT Payload
An SC/PR user, acting on behalf of a Singapore-registered company ```json {   "iss": "https://stg-id.corppass.gov.sg",   "aud": "vOIljWVrGyBMK6f31QYq",   "iat": 1623162109,   "exp": 1623165709,   "nonce": "ZEF+97zc3YZP7huv6nzKspfabDv0wRtce/aVNud23vU=",   "amr": ["pwd", "sms"],   "at_hash": "6J4VlBBQpbAyy1NL4NBW-Q", "sub": "T09LL0001B", "sub_type": "entity", "sub_attributes": { "entity_type": "UEN", "entity_reg_number": "T09LL0001B", "entity_coi": "SG", "entity_name": "My Example Company", "entity_uen_status": "Registered" }, "act": { "sub": "1c0cee38-3a8f-4f8a-83bc-7a0e4c59d6a9", "sub_type": "user", "sub_attributes": { "account_type": "standard", "identity_number": "S1234567P", "identity_coi": "SG", "name": "John Grisham" } } } ```
An SC/PR user, acting on behalf of a foreign company ```json {   "iss": "https://stg-id.corppass.gov.sg",   "aud": "vOIljWVrGyBMK6f31QYq",   "iat": 1623162109,   "exp": 1623165709,   "nonce": "ZEF+97zc3YZP7huv6nzKspfabDv0wRtce/aVNud23vU=",   "amr": ["pwd", "sms"],   "at_hash": "6J4VlBBQpbAyy1NL4NBW-Q", "sub": "C19001125A", "sub_type": "entity", "sub_attributes": { "entity_type": "NON-UEN", "entity_reg_number": "202219428Z", "entity_coi": "MY", "entity_name": "My Example Malaysia Company" }, "act": { "sub": "1c0cee38-3a8f-4f8a-83bc-7a0e4c59d6a9", "sub_type": "user", "sub_attributes": { "account_type": "standard", "identity_number": "S1234567P", "identity_coi": "SG", "name": "John Grisham" } } } ```
An SFA user, acting on behalf of a Singapore-registered company ```json {   "iss": "https://stg-id.corppass.gov.sg",   "aud": "vOIljWVrGyBMK6f31QYq",   "iat": 1623162109,   "exp": 1623165709,   "nonce": "ZEF+97zc3YZP7huv6nzKspfabDv0wRtce/aVNud23vU=",   "amr": ["pwd", "sms"],   "at_hash": "6J4VlBBQpbAyy1NL4NBW-Q", "sub": "T09LL0001B", "sub_type": "entity", "sub_attributes": { "entity_type": "UEN", "entity_reg_number": "T09LL0001B", "entity_coi": "SG", "entity_name": "My Example Company", "entity_uen_status": "Registered" }, "act": { "sub": "1c0cee38-3a8f-4f8a-83bc-7a0e4c59d6a9", "sub_type": "user", "sub_attributes": { "account_type": "foreign", "identity_number": "K28394589", "identity_coi": "MY", "name": "John Grisham" } } } ```
# Access Token The **Access Token** is a short-lived credential issued by Corppass after a successful authorization code exchange. It is used to authorize access to protected resources, such as the [Userinfo Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint). Unlike traditional Bearer tokens, this token is **Sender-Constrained**. It is cryptographically bound to the DPoP private key used during the token exchange request. ## Token Usage To access a protected endpoint, the client must present the Access Token in the `Authorization` header using the `DPoP` scheme (not `Bearer`). The request must also include a DPoP Proof in a separate header. This proof verifies that the client making the request holds the same private key that was used to request the token. ```http GET / Authorization: DPoP eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9... DPoP: ``` For a complete code sample showing how to construct the request headers and the accompanying DPoP proof, refer to [Userinfo Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint). ## Token Opacity Relying Parties (RPs) must treat the Access Token as an **opaque string**. * **Do not attempt to decode, parse, or inspect the token structure**. * **Do not rely on any internal claims** (e.g., `sub`, `exp`) found within the token for application logic. While the token is technically issued as a Signed JWT (JWS), its internal structure is **intended solely for the Resource Server (Corppass)** - for internal validation and rotation without breaking client integrations. ## Token Lifecycle * **Expiration:** The Access Token is valid for 10 minutes (600 seconds) from the time of issuance. * **Renewal:** Once expired, the client must initiate a new Authorization Flow to obtain a new token (refresh tokens are currently not supported). # 4. Userinfo Endpoint The **Userinfo Endpoint** allows Relying Parties (RPs) to retrieve detailed information about the authenticated Entity and Acting User. These details are not included in the ID Token and must be fetched explicitly after authentication. This is a Protected Resource, requiring a valid Access Token (obtained from the [Token Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/3.-token-endpoint)) for access. Currently, this endpoint primarily returns the user's Authorization Data (e.g., roles, authorized transactions), similar to the [Legacy Authorization Info Endpoint](/technical-specifications/corppass-authorization-api-legacy/endpoints/authorization-info-endpoint). #### Supported TLS Cipher Suites Please ensure you are using a supported cipher suite for this endpoint. Refer to [Supported TLS Cipher Suites](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/supported-tls-cipher-suites) for the full list. ## Request To obtain additional entity or user information, send a `GET` request to the Userinfo Endpoint URL obtained from the [OpenID Discovery Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/0.-well-known-endpoints/openid-discovery-endpoint) (`userinfo_endpoint`). {% hint style="info" %} Corppass supports both `GET` and `POST` methods for the Userinfo Endpoint. The [OIDC Specification (Section 5.3.2)](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) **recommends using the `GET` method**. {% endhint %} #### Sample GET Request (Recommended) ```http GET /userinfo HTTP/1.1 Authorization: DPoP eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9... DPoP: ``` #### Sample POST Request Request body is not required and will be ignored for `POST` request. ```http POST /userinfo HTTP/1.1 Content-Type: application/x-www-form-urlencoded; charset=utf-8 Authorization: DPoP eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9... DPoP: ``` ### Request Headers
HeaderRequiredDescription
Content-TypePOST only

Indicates the encoding format of the request body.

Validation:

  • Must be set to application/x-www-form-urlencoded; charset=utf-8.
AuthorizationYes

Carries the Access Token issued at the Token Endpoint, using the DPoP scheme instead of the typical Bearer scheme.

Example:

Authorization: DPoP <Access-Token>

DPoPYes

DPoP Proof JWT. A signed proof-of-possession JWT bound to the Access Token.

Validation:

  • This proof must include the ath (Access Token Hash) claim. This ensures the proof is cryptographically linked to the specific Access Token used in the request, preventing token misuse.

Refer to Demonstrating Proof of Possession section for more details.

## Success Response The Userinfo Endpoint returns a response in the form of a **JSON Web Encryption (JWE) object**, encrypted using the client's public encryption key configured in their JWKS object / JWKS endpoint. Inside the encrypted payload lies the **Signed JWT (JWS)**, signed using Corppass' private signing key. Refer to [ID Token](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/3.-token-endpoint/id-token) section for the decryption steps. ### Response Structure (Decoded Payload) The following table details the claims found in the decoded JWS payload:
ClaimTypeDescription
audStringAudience. The client ID of the Relying Party for whom this token is intended.
issStringIssuer. The URL of the Corppass server that issued the token.
iatNumberIssued At. The time the JWT was issued, expressed as a UNIX timestamp.
expNumber

Expiration Time. The expiration time of the JWT.

Value is set to 10 minutes from iat.

subStringSubject. The unique identifier for the authenticated user (in this case, we return Client ID).
auth_infoJSON String

Authorization information assigned to the user.

Refer to Auth Info section for more details.

Required scope: authinfo

tp_auth_infoJSON String

Third-party authorization information assigned to the user.

Refer to Third-party Auth Info section for more details.

Required scope: tpauthinfo

entity_infoJSON String

Business-related information about the entity the user is transacting on behalf of.

Refer to Entity Info section for more details.

Returned when

person_infoJSON String

Personal information about the user acting on behalf of the entity.

Refer to Person Info section for more details.

Returned when

corppass_infoJSON String

Information about the transacting user’s Corppass account.

Refer to Corppass Info section for more details.

Returned when

### Sample Response (Decoded Payload) {% code overflow="wrap" %} ```json { "iat": 1624086842, "exp": 1624087442, "aud": "vOIljWVrGyBMK6f31QYq", "iss": "https://id.corppass.gov.sg", "sub": "vOIljWVrGyBMK6f31QYq", "auth_info": { ... // truncated for brevity, refer to Auth Info page for more details }, "tp_auth_info": { ... // truncated for brevity, refer to Thrid-party Auth Info page for more details }, "entity_info": { ... // truncated for brevity, refer to Entity Info page for more details }, "person_info": { ... // truncated for brevity, refer to Person Info page for more details }, "corppass_info": { ... // truncated for brevity, refer to Corppass Info page for more details } } ``` {% endcode %} ## Error Response If the Access Token is invalid, expired, or the DPoP proof fails, Corppass returns a JSON response containing an error code and description. {% hint style="warning" %} If the request lacks authentication altogether (e.g., no `Authorization` header or unsupported scheme), **Corppass will return HTTP 401 without including any error code, description, or body.** This prevents revealing information about authentication requirements to unauthenticated or potentially malicious clients, as recommended by [RFC 6750 Section 3.1.](https://www.rfc-editor.org/rfc/rfc6750.html#section-3.1) {% endhint %} ### Response Header The response will always include the `WWW-Authenticate` header when the access token is missing or invalid. For DPoP-bound tokens, this header specifically indicates issues with the token or its associated proof. ```http WWW-Authenticate: DPoP error="invalid_dpop_proof", error_description="DPoP proof iat is not recent enough" ``` ### Response Body
FieldTypeDescription
errorString

A standardised error code identifying the type of error that occurred.


See Error Codes below for a complete list of possible values.

error_descriptionStringA human-readable text description providing additional details about the error.
#### Error Codes
Error CodeHTTP StatusDescription
invalid_request400

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.
  • The client’s JWKS endpoint is not reachable.
  • The JWKS object is empty or the encryption key is not available.
  • 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.
  • Your JWKS endpoint is accessible and returns a valid key set that complies with the required specification.
invalid_client401

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_token401Access token is expired, invalid, or not properly bound.
invalid_dpop_proof401

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.
### Sample Response 
{
  "error": "invalid_dpop_proof",
  "error_description": "DPoP proof iat is not recent enough"
}
# Auth Info The `auth_info` claim provides **authorization details** about the **user acting on behalf of the entity**. {% hint style="info" %} This claim is only returned in the [Userinfo Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint) response when **`authinfo`** scope is requested. {% endhint %} ## `auth_info` Attributes
FieldData TypeLengthDescription
Result_SetJSON-Digital Service authorization result set.
#### `auth_info.Result_Set` attributes
FieldData TypeLengthDescription
ESrvc_Row_CountInteger10

The number of Digital Services for which the authorizations are present in the Result_Set.ESrvc_Result JSON object.

Returns 0 if ESrvc_Result is empty.

ESrvc_ResultArray of JSON-

Array of JSON objects, each containing authorization details for the Digital Service.

Refer to E-Service item attributes for more details.

#### E-Service item attributes (`auth_info.Result_Set.ESrvc_Result[]` item) Contains authorization details for the digital service.
FieldData TypeLengthDescription
CPESrvcIDString25The readable ID of the Digital Service.
Auth_Result_SetJSON-

JSON object. Contains user assignment details for the Digital Service.

Refer to User Assignment Result Set attributes for more details.

#### User Assignment Result Set attributes (`auth_info.Result_Set.ESrvc_Result[].Auth_Result_Set`)
FieldData TypeLengthDescription
Row_CountInteger10

The number of rows included in the auth result set (ie. number of assignments the user has for the e-service).


e.g. If the user is granted two separate assignments to the same e-service on behalf of the same entity, this value will be 2 . The following result set will contain then contain two objects, each representing one assignment.

RowArray of JSON-

Array of JSON objects, where each JSON object describes a single third-party assignment.

Refer to User Assignment Item attributes for more details.

#### User Assignment Item attributes (`auth_info.Result_Set.ESrvc_Result[].Auth_Result_Set.Row[]` item)
FieldData TypeLengthDescription
CPEntID_SUBString32Sub-UEN value of that entity to which the user is assigned the authorization.

If the Digital Service requires a mandatory Sub-UEN attribute but no value was supplied, "ERROR_MISSING_VALUE" will be returned for the field.
CPRoleString20The role assigned to the user in this particular authorisation.
StartDateString (format YYYY-MM-DD)10The start date for validity of the authorisation.
EndDateString (format YYYY-MM-DD)10The end date for validity of the authorisation.
ParameterArray of JSON-

This is an optional array of parameters (JSON objects containing only name and value pair attributes) defined by Digital Service administrator.

These parameters will be populated as required. These parameters use a name-value pair format.

If no parameters are defined this will be returned as empty array.

If a parameter is defined as mandatory by the Digital Service administrator but no value was supplied, "ERROR_MISSING_VALUE" will be returned for the field.

Refer to User Assignment Parameter attributes for more details.

#### User Assignment Parameter attributes (`auth_info.Result_Set.ESrvc_Result[].Auth_Result_Set.Row[].Parameter`)
FieldData TypeLengthDescription
nameString30Parameter name defined by defined by Digital Service administrator
valueString66Parameter value defined by defined by Digital Service administrator
## Sample Payload
User with two authorisations Authorization info payload for a User with two authorisations: * One to e-service `SAMPLE-ESERVICE` * One to e-service `OTHER-ESERVICE` {% code lineNumbers="true" %} ```json { "auth_info": { "Result_Set": { "ESrvc_Row_Count": 2, "ESrvc_Result": [ { "CPESrvcID": "SAMPLE-ESERVICE", "Auth_Result_Set": { "Row_Count": 1, "Row": [ { "CPEntID_SUB": "", "CPRole": "Approver", "StartDate": "2017-11-14", "EndDate": "9999-12-31", "Parameter": [ { "name": "Effective YA", "value": "2020" }, ] } ] } }, { "CPESrvcID": "OTHER-ESERVICE", "Auth_Result_Set": { "Row_Count": 1, "Row": [ { "CPEntID_SUB": "", "CPRole": "Editor", "StartDate": "2017-11-14", "EndDate": "9999-12-31", "Parameter": [] } ] } } ] } } } ``` {% endcode %}
# Third-party Auth Info The `tp_auth_info` claim provides **third-party authorization details** about the **user acting on behalf of the entity**. {% hint style="info" %} This claim is only returned in the [Userinfo Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint) response when 1. **`tpauthinfo`** scope is requested. 2. The digital service **supports third-party** functionality on Corppass. 3. The user has **third-party authorisations** for the digital service. {% endhint %} {% hint style="info" %} **Note:** A user may have multiple third-party authorizations for a given Digital Service. *Example:* For the GST Digital Service, a user from a third-party firm is authorized to file GST on behalf of 5 client entities. In this case, all 5 third-party authorizations will be returned in the `tp_auth_info` claim. {% endhint %} ## `tp_auth_info` **Attributes**
FieldData TypeLengthDescription
Result_SetJSON-Digital Service authorization result set.
#### `tp_auth_info.Result_Set` attributes
FieldData TypeLengthDescription
ESrvc_Row_CountInteger10

The number of Digital Services for which the authorizations are present in the Result_Set.ESrvc_Result JSON object.

For third-party authorisations, this value will always be set to 1.

ESrvc_ResultArray of JSON-

Array of JSON objects, each containing third-party authorization details for the Digital Service.

For third-party authorisations, there will only be a single JSON object.

Refer to E-Service item attributes for more details.

#### E-Service item attributes (`tp_auth_info.Result_Set.ESrvc_Result[]` item) Contains authorization details for the digital service.
FieldData TypeLengthDescription
CPESrvcIDString25The readable ID of the Digital Service.
Auth_SetJSON-

JSON object. Contains third-party assignment details for the Digital Service.

Refer to Third-Party Assignment Result Set attributes for more details.

#### Third-Party Assignment Result Set attributes (`tp_auth_info.Result_Set.ESrvc_Result[].Auth_Set`)
FieldData TypeLengthDescription
ENT_ROW_COUNTInteger10Indicates the number of rows in the third-party assignment.

This is equal to the number of client entities that the user is authorized as third party for that Digital Service.
TP_AuthArray of JSON-

Array of JSON objects, each JSON object represents an third-party authorization of the user for the client entity.

Refer to Third-Party Assignment Item attributes for more details.

#### Third-Party Assignment Item attributes (`tp_auth_info.Result_Set.ESrvc_Result[].Auth_Set.TP_Auth[]` item)
FieldData TypeLengthDescription
CP_Clnt_IDString10Client entity ID (eg. UEN).
CP_ClntEnt_TYPEString10

Client entity type. The possible values for entity type are:

  • UEN
  • NON-UEN (Includes non-UEN entities as well as ASGD/ITR entities)
  • GSTN
Auth_Result_SetArray of JSON-

JSON object. Contains third-party user assignment details for the client entity.

Refer to User Assignment Result Set attributes for more details.

#### User Assignment Result Set attributes (`tp_auth_info.Result_Set.ESrvc_Result[].Auth_Set.TP_Auth[].Auth_Result_Set`)
FieldData TypeLengthDescription
Row_CountInteger10

The count of the number of rows included in the result set (ie. number of third-party assignments the user has for the given client entity).

E.g. If the user is granted two separate third-party assignments to the same e-service on behalf of the same entity, this value will be 2 . The following result set will contain then contain two objects, each representing one assignment.

RowArray of JSON-

Array of JSON objects, where each JSON object describes a single third-party assignment.

Refer to User Assignment Item attributes for more details.

#### User Assignment Item attributes (`tp_auth_info.Result_Set.ESrvc_Result[].Auth_Set.TP_Auth[].Auth_Result_Set.Row[]` item)
FieldData TypeLengthDescription
CP_ClntEnt_SUBString32Sub-UEN value of that entity to which the user is assigned the authorization.

If the Digital Service requires a mandatory Sub-UEN attribute but no value was supplied, "ERROR_MISSING_VALUE" will be returned for the field.
CPRoleString20The role assigned to the user in this particular authorisation.
StartDateString (format YYYY-MM-DD)10The start date for validity of the authorisation.
EndDateString (format YYYY-MM-DD)10The end date for validity of the authorisation.
ParameterArray of JSON-

This is an optional array of parameters (JSON objects containing only name and value pair attributes) defined by Digital Service administrator.

These parameters will be populated as required. These parameters use a name-value pair format.

If no parameters are defined this will be returned as empty array.

If a parameter is defined as mandatory by the Digital Service administrator but no value was supplied, "ERROR_MISSING_VALUE" will be returned for the field.

Refer to User Assignment Parameter attributes for more details.

#### User Assignment Parameter attributes (`tp_auth_info.Result_Set.ESrvc_Result[].Auth_Set.TP_Auth[].Auth_Result_Set.Row[].Parameter`)
FieldData TypeLengthDescription
nameString30Parameter name defined by defined by Digital Service administrator
valueString66Parameter value defined by defined by Digital Service administrator
## Sample Payload
User with two third-party authorisations Third-Party authorization info payload for a User with **two** third-party authorisations for the e-service `SAMPLE-ESERVICE`: * One acting on behalf of entity `T00YY8888X` * One acting on behalf of entity `T99BB0000A` {% code lineNumbers="true" %} ```json { "tp_auth_info": { "Result_Set": { "ESrvc_Row_Count": 1, "ESrvc_Result": [ { "CPESrvcID": "SAMPLE-ESERVICE", "Auth_Set": { "ENT_ROW_COUNT": 2, "TP_Auth": [ { "CP_Clnt_ID": "T00YY8888X", "CP_ClntEnt_TYPE": "UEN", "Auth_Result_Set": { "Row_Count": 1, "Row": [ { "CP_ClntEnt_SUB": "", "CPRole": "Maker", "StartDate": "2025-09-05", "EndDate": "9999-12-31", "Parameter": [] } ] } }, { "CP_Clnt_ID": "T99BB0000A", "CP_ClntEnt_TYPE": "UEN", "Auth_Result_Set": { "Row_Count": 1, "Row": [ { "CP_ClntEnt_SUB": "", "CPRole": "Checker", "StartDate": "2025-09-05", "EndDate": "9999-12-31", "Parameter": [] } ] } } ] } } ] } }, } ``` {% endcode %}
# Entity Info The `entity_info` claim provides **business-related information** about the **entity the user is transacting on behalf of**. {% hint style="info" %} This claim is only returned in the [Userinfo Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint) response when 1. [**Myinfo Business entity scopes**](/technical-specifications/corppass-authorization-api-fapi-2.0/scopes/myinfo-business-scopes/entity-scopes) are requested. 2. The digital service is a [**Myinfo Business application**](/products/myinfo-business). {% endhint %} ## `entity_info` Attributes Attributes in `entity_info` are scope-driven. Each attribute maps directly to a requested [Entity Scope](/technical-specifications/corppass-authorization-api-fapi-2.0/scopes/myinfo-business-scopes/entity-scopes) and will only be included in the response if that scope is present. For the full set of attributes and their structures, refer to the **OpenAPI specifications**: {% file src="/files/lXMe7LqYQSE4LGboBJ16" %} ### Common Attribute Patterns Depending on the type of data, attributes may follow one of the patterns below: **Pattern A: Metadata + Value** Used when the field contains a single value. ```json { "classification": "C", "source": "1", "lastupdated": "2019-03-26", "value": "2018-01-31" } ``` **Pattern B: Metadata + Code + Description** Used for coded values with a human-readable description. ```json { "classification": "C", "source": "1", "lastupdated": "2019-03-26", "code": "LC", "desc": "Local Company" } ``` **Pattern C: Metadata at Parent Level, Value in Child Fields** Used when multiple related values share the same metadata. ```json { "appointment_date": { "value": "2018-01-31" }, "classification": "C", "source": "1", "lastupdated": "2019-03-26" } ``` **Pattern D: Metadata at Parent Level, Code/Desc in Child Fields** Used when child fields contain coded values. ```json { "position": { "code": "23", "desc": "Partner" }, "classification": "C", "source": "1", "lastupdated": "2019-01-01" } ``` **Pattern E: Unavailable Data** Used when data is not available from the source. ```json { "classification": "C", "source": "1", "lastupdated": "2019-03-26", "unavailable": true } ``` **Note:** * Not all attributes follow the same structure. * The exact structure depends on the type of data being returned. * Developers should refer to the OpenAPI specification for the complete schema definition. ## Sample Payload
entity_info.basic_profile.name attribute for the scope entity.basic_profile.name ```json { "entity_info": { "basic_profile": { "name": { "classification": "C", "lastupdated": "2018-01-31", "source": "1", "value": "ABC LL" } } } } ```
# Person Info The `person_info` claim provides **personal information** about the **user acting on behalf of the entity**. {% hint style="info" %} This claim is only returned in the [Userinfo Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint) response when 1. [**Myinfo Business person scopes**](/technical-specifications/corppass-authorization-api-fapi-2.0/scopes/myinfo-business-scopes/person-scopes) are requested. 2. The digital service is a [**Myinfo Business application**](/products/myinfo-business). {% endhint %} ## `person_info` Attributes Attributes in `person_info` are scope-driven. Each attribute maps directly to a requested [Person Scope](/technical-specifications/corppass-authorization-api-fapi-2.0/scopes/myinfo-business-scopes/person-scopes) and will only be included in the response if that scope is present. For the full set of attributes and their structures, refer to the **OpenAPI specifications**: {% file src="/files/lXMe7LqYQSE4LGboBJ16" %} Refer to [common attribute patterns](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint/entity-info#common-attribute-patterns) for some of the common attribute patterns. ## Sample Payload
person_info.name attribute for the scope user.name ```json { "person_info": { "name": { "classification": "C", "lastupdated": "2019-03-26", "source": "1", "value": "TAN XIAO HUI" } } } ```
# Corppass Info The `corppass_info` claim provides information about the **transacting user’s Corppass account**. {% hint style="info" %} This claim is only returned in the [Userinfo Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint) response when 1. [**Myinfo Business Corppass scopes**](/technical-specifications/corppass-authorization-api-fapi-2.0/scopes/myinfo-business-scopes/corppass-scopes) are requested. 2. The digital service is a [**Myinfo Business application**](/products/myinfo-business). {% endhint %} ## `corppass_info` Attributes
FieldData TypeDescription
emailString

Corppass registered email address.

Required scope: corppass.email

email_verifiedBoolean

Indicates if the Corppass registered email has been verified.

Required scope: corppass.email

## Sample Payload
email attributes for the scope corppass.email ```json { "corppass_info": { "email": "john@corppass.gov.sg", "email_verified": true } } ```
# Supported TLS Cipher Suites In line with the enhanced security requirements of FAPI 2.0, only the following cipher suites are supported: | TLS Version | Allowed Ciphers | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TLS v1.3 | All ciphers | | TLS v1.2 |
  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-ECDSA-AES256-GCM-SHA384
| # Scopes Scopes define the level of access a Relying Party (RP) is requesting from Corppass during an authorization request. Each scope corresponds to a specific set of claims or datasets that the RP may access. Once the user authorises the request, the claims associated with the requested scopes are returned either in ID token (via the [Token Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/3.-token-endpoint)) and/or through the [Userinfo Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint), depending on the type of digital service application. ## Usage When initiating an authorization request via , RPs specify the required scopes in the `scope` parameter. Multiple scopes are space-separated. Example: ``` scope=openid authinfo user.identity entity.identity entity.basic_profile.name ``` Refer to [Pushed Authorization Request (PAR)](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/1.-pushed-authorization-request-par-endpoint) for detailed specifications on constructing the request. ## Available Scopes
Scope CategoryDescription
Standard Scopes

Corppass standard scopes provide access to identity information about the transacting user, and the entity that the user is transacting on behalf of.

These include:

Available to all Corppass applications.

Myinfo Business Scopes

Myinfo Business scopes provide access to entity and personal information about the acting user and the entity they represent.

These include:

  • Entity scopes, providing access to business-related information about the entity the user is transacting on behalf of.
  • Person scopes, providing access to personal information about the transacting user.
  • Corppass scopes, providing access to information about the transacting user's Corppass account.

Available to only Myinfo Business applications.

# Corppass Standard Scopes Corppass standard scopes provide access to identity information about the transacting user, and the entity that the user is transacting on behalf of. These scopes are **available to all Corppass applications**. ## Protocol Scopes Protocol scopes are mandatory scopes required for authentication and authorization.
ScopeDescription
openid

Mandatory scope to indicate the request is an OpenID Connect flow.

The scope must be included in the scope parameter of an authorization request.

## Authorization Scopes Authorization scopes provide access to authorization details about the transacting user.
ScopeDescriptionData AccessEndpoint
authinfoView authorization details about the transacting user.
auth_info
UserInfo
tpauthinfoView third-party authorization details about the transacting user.
tp_auth_info
UserInfo
## Entity Scopes Entity scopes provide access to profile information about the entity that the user is transacting on behalf of.
ScopeDescription & EndpointData AccessEndpoint
entity.identity

View entity identity, includes:

  • entity type
  • registration number
  • country of incorporation using ISO 3166-1 alpha-2 standard
    Refer to ISO 3166 for possible values.
sub_attributes:
- entity_type
- entity_reg_number
- entity_coi
Token
entity.basic_profile.nameView entity name.
sub_attributes:
- entity_name
Token
entity.basic_profile.uen_statusView entity UEN status.
sub_attributes:
- entity_uen_status
Token
## User Scopes User scopes provide access to profile information about the transacting user.
ScopeDescriptionData AccessEndpoint
user.identity

View acting user's identity, includes:

  • account type
  • identity number
  • country of issuance using ISO 3166-1 alpha-2 standard
    Refer to ISO 3166 for possible values.
act.sub_attributes:
- account_type
- identity_number
- identity_coi
Token
user.nameView acting user's name.
act.sub_attributes:
- name
Token
# Myinfo Business Scopes Myinfo Business scopes provide access to entity and personal information about the acting user and the entity they represent. These scopes are **only available to** [**Myinfo Business applications**](/products/myinfo-business). Corresponding Myinfo Business data is returned via the [**Userinfo Endpoint**](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint) as: * `entity_info` for [Myinfo Business entity scopes](/technical-specifications/corppass-authorization-api-fapi-2.0/scopes/myinfo-business-scopes/entity-scopes), with the **`entity.`** prefix * `person_info` for [Myinfo Business person scopes](/technical-specifications/corppass-authorization-api-fapi-2.0/scopes/myinfo-business-scopes/person-scopes), with the **`user.`** prefix * `corppass_info` for [Myinfo Business Corppass scopes](/technical-specifications/corppass-authorization-api-fapi-2.0/scopes/myinfo-business-scopes/corppass-scopes), with the **`corppass.`** prefix #### Example
ScopeData returned in Userinfo Response
entity.basic_profile.name

entity_info.basic_profile.name

{
  "entity_info": {
    "basic_profile": {
      "name": {
        "classification": "C",
        "lastupdated": "2018-01-31",
        "source": "1",
        "value": "ABC LL"
      }
    }
  }
}
user.name

person_info.name

{
  "person_info": {
    "name": {
       "classification": "C",
       "lastupdated": "2019-03-26",
       "source": "1",
       "value": "TAN XIAO HUI"
    }
  }
}
corppass.email

corppass_info.email

corppass_info.email_verified

{
  "corppass_info": {
    "email": "john@corppass.gov.sg",
    "email_verified": true
  }
}
# Entity Scopes Myinfo Business entity scopes provide access to **business-related information** about the **entity the user is transacting on behalf of**. These scopes are only available to [Myinfo Business applications](/products/myinfo-business). The corresponding data is returned via the [Userinfo Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint) under `entity_info`. Refer to [Entity Info](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint/entity-info) for more details. ## Basic Profile
NameScopeDescription
Company Typeentity.basic_profile.company_typeType of company.
Refer to the OpenAPI specification for possible values.
Constitutionentity.basic_profile.constitutionConstitution of Business or Public Accounting Firms.
Refer to the OpenAPI specification for possible values.
Country of Incorporationentity.basic_profile.country_of_incorporationCountry of incorporation using ISO 3166-1 alpha-2 standard. Refer to ISO 3166 for possible values.
Expiry Dateentity.basic_profile.expiry_dateExpiry date in "YYYY-MM-DD" format.
Nameentity.basic_profile.nameEntity's registered name.
Primary Activityentity.basic_profile.primary_activityPrimary activity using Singapore Standard Industrial Classification (SSIC) 2025 edition.
Refer to Singapore Standard Industrial Classification (SSIC) for possible values.
Registration Dateentity.basic_profile.registration_dateRegistration date in "YYYY-MM-DD" format.
Registration Numberentity.basic_profile.registration_numberUnique Entity Number (UEN).
Secondary Activityentity.basic_profile.secondary_activitySecondary activity using Singapore Standard Industrial Classification (SSIC) 2025 edition.
Refer to Singapore Standard Industrial Classification (SSIC) for possible values.
Typeentity.basic_profile.type

Type of entity.

Refer to the OpenAPI specification for possible values. If this field is LC or FC, refer to company_type. If this field is BN or PF, refer to constitution.

UEN Statusentity.basic_profile.uen_status

UEN registration status.

Refer to the OpenAPI specification for possible values.

## Address
NameScopeDescription
Addressentity.addressEntity's latest registered address details.
## History
NameScopeDescription
Previous Nameentity.history.previous_names.previous_namePrevious name.
Previous Name Effective Dateentity.history.previous_names.previous_name_effective_datePrevious name effective date in "YYYY-MM-DD" date.
Previous Registration Numberentity.history.previous_registration_numbers.previous_registration_numberPrevious registration number.
## Appointments
NameScopeDescription
Appointment Dateentity.appointments.appointment_datePosition appointment date in "YYYY-MM-DD" format.
Appointment Positionentity.appointments.position

Position of the appointment holder.

Refer to the OpenAPI specification for possible values.

Appointment Position Categoryentity.appointments.category

Position category of the appointment holder.

Refer to the OpenAPI specification for possible values.

Designationentity.appointments.designationDesignation of the appointment holder.
Entity Appointment - Nameentity.appointments.entity_appointment.nameEntity's registered name.
Entity Appointment - Registration Numberentity.appointments.entity_appointment.registration_numberUnique Entity Number (UEN) / Foreign Business Registration Number (FBRN).
Entity Appointment - Typeentity.appointments.entity_appointment.type

Type of entity.

Refer to the OpenAPI specification for possible values.

Individual Appointment - ID Numberentity.appointments.individual_appointment.id_number

ID number of person as lodged by the entity at registration.

Note: This ID is not verified by government.

Individual Appointment - ID Typeentity.appointments.individual_appointment.id_typeType of identification document. Refer to the OpenAPI specification for possible values.
Individual Appointment - Nameentity.appointments.individual_appointment.name

Name of person as lodged by entity at registration.

Note: This name is not verified by government.

Individual Appointment - Nationalityentity.appointments.individual_appointment.nationality

Nationality/Citizenship using SG-DRM data standard.

Refer to the OpenAPI specification for possible values.

## Stakeholders
NameScopeDescription
Entity Shareholder - Nameentity.shareholders.entity_shareholder.nameEntity's registered name.
Entity Shareholder - Registration Numberentity.shareholders.entity_shareholder.registration_numberUnique Entity Number (UEN) / Foreign Business Registration Number (FBRN).
Entity Shareholder - Typeentity.shareholders.entity_shareholder.type

Type of entity.

Refer to the OpenAPI specification for possible values.

Individual Shareholder - ID Numberentity.shareholders.individual_shareholder.id_number

ID number of person as lodged by the entity at registration.

Note: This ID is not verified by government.

Individual Shareholder - ID Typeentity.shareholders.individual_shareholder.id_type

Type of identification document.

Refer to the OpenAPI specification for possible values.

Individual Shareholder - Nameentity.shareholders.individual_shareholder.name

Name of person as lodged by entity at registration.

Note: This name is not verified by government.

Individual Shareholder - Nationalityentity.shareholders.individual_shareholder.nationality

Nationality/Citizenship using SG-DRM data standard.

Refer to the OpenAPI specification for possible values.

Shareholders - Allocationentity.shareholders.allocationNumber of shares allotted.
Shareholders - Categoryentity.shareholders.category

Shareholder category.

Refer to the OpenAPI specification for possible values.

Shareholders - Currencyentity.shareholders.currency

Indicates the currency that the shares are held in.

Refer to the OpenAPI specification for possible values.

Shareholders - Share Typeentity.shareholders.share_type

Type of shares.

Refer to the OpenAPI specification for possible values.

## Capitals
NameScopeDescription
Capitals - Currencyentity.capitals.currency

Currency.

Refer to the OpenAPI specification for possible values.

Capitals - Issued Amountentity.capitals.issued_amount

Issued capital monetary amount.

Refer to currency for the currency.

Capitals - Paid-up Amountentity.capitals.paid_up_amount

Paid-up capital monetary amount.

Refer to currency for the currency.

Capitals - Share Allotted Numberentity.capitals.share_allotted_numberAllotted number of capital shares, not to be confused with currency as monetary sense.
Capitals - Share Typeentity.capitals.share_type

Type of capital shares.

Refer to the OpenAPI specification for possible values.

## Financials
NameScopeDescription
Audit statusentity.financials.is_auditedWhether financial statements are audited.
Company Financial - Profit Loss After Taxentity.financials.company_financial.profit_loss_after_tax

Monetary value for company profit (loss) after tax from continuing operations in the fiscal period.

Refer to currency for the currency.

Company Financial - Profit Loss Before Taxentity.financials.company_financial.profit_loss_before_tax

Monetary value for company profit (loss) before tax from continuing operations in the fiscal period.

Refer to currency for the currency.

Company Financial - Revenueentity.financials.company_financial.revenue

Monetary value for company revenue in the fiscal period.

Refer to currency for the currency.

Currencyentity.financials.currency

Currency.

Refer to the OpenAPI specification for possible values.

Financial Period End Dateentity.financials.current_period_end_dateCurrent financial period end date in "YYYY-MM-DD" format.
Financial Period Start Dateentity.financials.current_period_start_dateCurrent financial period start date in "YYYY-MM-DD" format.
Group Financial - Profit Loss After Taxentity.financials.group_financial.profit_loss_after_tax

Monetary value for group profit (loss) after tax from continuing operations in the fiscal period.

Refer to currency for the currency.

Group Financial - Profit Loss Before Taxentity.financials.group_financial.profit_loss_before_tax

Monetary value for group profit (loss) before tax from continuing operations in the fiscal period.

Refer to currency for the currency.

Group Financial - Revenueentity.financials.group_financial.revenue

Monetary value for group revenue in the fiscal period.

Refer to currency for the currency.

Group Financial - Share Capitalentity.financials.group_financial.share_capital

Monetary value for group share capital in the fiscal period.

Refer to currency for the currency.

## Grants
NameScopeDescription
Development Categoryentity.grants.development_category

Development category.

Refer to the OpenAPI specification for possible values.

Functional Areaentity.grants.functional_area

Functional area.

Refer to the OpenAPI specification for possible values.

Grant Submitted Dateentity.grants.submitted_on_dateDate that the grant was submitted in "YYYY-MM-DD" format.
Grants Approved Amountentity.grants.approved_amountMonetary amount approved by the grant. Currency is in SGD (Singapore Dollar).
Grants Last Update Dateentity.grants.last_update_dateDate that the grant was last updated in "YYYY-MM-DD" format.
Grants Statusentity.grants.status

Status.

Refer to the OpenAPI specification for possible values.

Grants typeentity.grants.type

Type of grant.

Refer to the OpenAPI specification for possible values.

## Licences
NameScopeDescription
Issuance Agencyentity.licences.issuance_agency

Licence issuance agency.

Refer to the OpenAPI specification for possible values.

Licence Expiry Dateentity.licences.expiry_dateLicence expiry date in "YYYY-MM-DD" format.
Licence Issue Dateentity.licences.issue_dateLicence issue date in "YYYY-MM-DD" format.
Licence Nameentity.licences.licence_nameLicence name.
Licence Numberentity.licences.licence_numberUnique licence number assign by agencies.
## Builders
NameScopeDescription
Builders Licenceentity.builders.licence

Type of builder licence.

Refer to the OpenAPI specification for possible values.

Builders Licence Expiry Dateentity.builders.licence_expiry_dateBuilder licence expiry date in "YYYY-MM-DD" format.
## Contractors
NameScopeDescription
Contractors CRS Expiry Dateentity.contractors.crs_expiry_dateContractors Registration System (CRS) expiry date in "YYYY-MM-DD" format.
Contractors Workheadentity.contractors.workhead

Type of contractor workhead.

Refer to the OpenAPI specification for possible values.

Contractors Workhead Financial Gradeentity.contractors.workhead_financial_grade

Contractor workhead financial grade.

Refer to the OpenAPI specification for possible values.

# Person Scopes Myinfo Business person scopes provide access to **personal information** about the **user acting on behalf of the entity**. These scopes are only available to [Myinfo Business applications](/products/myinfo-business). The corresponding data is returned via the [Userinfo Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint) under `person_info`. Refer to [Person Info](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint/person-info) for more details. ## Personal
NameScopeAvailable ForDescription
NRIC / FINuser.uinfinSC, PR, FINNRIC number or FIN of user. NRIC number is the unique identifier given to every Singapore Citizens (SC) and Permanent Residents (PR), while FIN is the unique identifier for Foreigners.
Alias Nameuser.aliasnameSC, PRRefers to an alternate/additional name of the user that is legally recognised.
Date of Birthuser.dobSC, PR, FIN
Employment Sectoruser.employmentsectorFINRefers to the employment sector of a FIN holder. Only applies to a FIN holder with a valid pass issued by MOM.
Hanyu Pinyin Nameuser.hanyupinyinnameSC, PRRefers to the officially romanised Chinese name of the user.
Hanyu Pinyin Alias Nameuser.hanyupinyinaliasnameSC, PRRefers to the legally-recognised alternate officially romanised Chinese name of the user.
Type of Housinguser.housingtypeSC, PR, FINNote that this is determined based on user's Registered Address (if it is not a HDB flat). It has no association with housing ownership.
Refer to the OpenAPI specification for possible values.
Married Nameuser.marriednameSC, PRRefers to the family name or surname adopted by the user upon marriage.
Marital Statususer.maritalSC, PR

Marital status is based on records that had been reasonably verified by the relevant Government agency upon receipt.

Marital Status must be made editable at digital services even though data source is MSF.

Refer to the OpenAPI specification for possible values.

Principal Nameuser.nameSC, PR, FINFull name of user printed on NRIC or FIN card. Includes Surname if any.
Nationality/Citizenshipuser.nationalitySC, PR, FINRefer to the OpenAPI specification for possible values.
Passport Expiry Dateuser.passportexpirydateSCPassport expiry date of the user.
Passport Numberuser.passportnumberSCPassport number of the user.
Pass Typeuser.passtypeFINRefer to the OpenAPI specification for possible values.
Pass Statususer.passstatusFIN

This refers to the pass status of a FIN holder.

Available values:

  • Live
  • Approved. (Interim status in which the FIN holder has yet to receive the pass)

Note that this only applies to a FIN holder with a valid pass issued by ICA/MOM.

Residential Statususer.residentialstatusSC, PRIndicate if the user is a Citizen, PR or others. Blank value will be returned for FIN holder.
Refer to the OpenAPI specification for possible values.
Secondary Raceuser.secondaryraceSC, PR

Refers to secondary racial category of the Person, if any.

Refer to the OpenAPI specification for possible values.

Raceuser.raceSC, PR, FINRefer to the OpenAPI specification for possible values.
Sexuser.sexSC, PR, FIN

Gender of the user.

Refer to the OpenAPI specification for possible values.

Registered Addressuser.regaddSC, PR, FIN

For SC/PR - Registered address is the address that is printed on the NRIC card.

For FIN - Registered address is applicable for foreigners under the following Pass Types:

  • ICA-issued Passes

    • Long Term Visit Pass / Long Term Visit Pass +
    • Student Pass
    • Immigration Exemption Order

  • MOM-issued Passes

    • S Pass
    • Employment Pass
    • Personalised Employment Pass
    • EntrePass
    • Dependent Pass
## Vehicle and Driving License
NameScopeDescription
Driving Licence - Provisional Driving Licence Validityuser.drivinglicence.pdl.validityValidity of PDL (e.g. V - Valid, E - Expired, I - Invalid, N - Not Holding PDL).
Driving Licence - Qualified Driving Licence Classuser.drivinglicence.qdl.classesQDL Class. Includes Issue Date (e.g. 2B, 2018-01-01).
Driving Licence - Qualified Driving Licence Validityuser.drivinglicence.qdl.validityValidity of QDL (e.g. V - Valid, E - Expired, I - Invalid, N - Not Holding QDL).
Vehicles - Vehicle Makeuser.vehicles.makeVehicle Make such as 'TOYOTA', 'HONDA', 'AUDI'.
Vehicles - Vehicle Modeluser.vehicles.modelVehicle Model such as 'COROLLA ALTIS CLASSIC 1.6 CVT', 'HRV 1.5 DX CVT'.
Vehicles - Vehicle Numberuser.vehicles.vehiclenoVehicle Registration Number displayed on the vehicle number plates.
## Property
NameScopeDescription
HDB Ownership - Addressuser.hdbownership.addressFlat Address.
HDB Ownership - Date of Purchaseuser.hdbownership.dateofpurchaseEffective Date of flat purchase.
HDB Ownership - Type of HDB Dwellinguser.hdbownership.hdbtype

HDB Flat Type.

Refer to the OpenAPI specification for possible values.

HDB Ownership - Monthly Loan Instalmentuser.hdbownership.monthlyloaninstalmentMonthly instalment payable to HDB.
HDB Ownership - Number of Ownersuser.hdbownership.noofowners

Number of Owners.

Note that this does not include executors, administrators or trustees.

HDB Ownership - Outstanding HDB Loan Balanceuser.hdbownership.outstandingloanbalanceOutstanding amount payable to HDB.
HDB Ownership - Type of HDB Dwellinguser.hdbtype

HDB Flat Type.

Refer to the OpenAPI specification for possible values.

## Finance
NameScopeDescription
CPF Contribution History (up to 15 months)user.cpfcontributions

The Central Provident Fund is a mandatory social security savings scheme funded by contributions from employers and employees.

For each contribution record, the 4 fields (Paid for Month, Paid On, Employer Name, Contribution Total) will be provided.

Only Contribution(s) related to employment will be provided. Other contributions, such as self-employed or government top-ups, are presently excluded.

CPF will return the contributions received (or paid on) in the past 15 months up to the preceding month. Note that a member could have multiple contributions per month from the same employer.

  • Example 1:
    If the query is made in March-24, contribution provided will be for contribution received in the period from January-23 to March-24 (inclusive). This is provided that March-24 contribution had been received, else contribution provided will be January-23 to February-24.
  • Example 2:
    Assuming a member has a late CPF contribution for work done in Nov-22 (beyond January-23 to March-24) that was credited only in Jan-23. If the query is made in March-24, contribution provided will include the late contribution as it was received in the period from January-23 to March-24. The contribution period range of January-23 to March-24 (inclusive) remains.

Refer to the CPF display guidelines.

CPF Housing Withdrawaluser.cpfhousingwithdrawal

The Central Provident Fund is a mandatory social security savings scheme funded by contributions from employers and employees.

The CPF Housing Withdrawal data include the following for the purpose of financing a HDB flat or private residential property:

  • Address: This is the registered address of property which withdrawal is made.
  • Principal Withdrawal Amount: This is the CPF principal amount user has withdrawn under the CPF housing schemes.
  • Monthly Instalment Amount: This is the monthly CPF deduction for payment of user's property.
  • Accrued Interest Amount: This is the interest that user would have earned had user's savings remained in the CPF account.
  • Total Amount of CPF Allowed for Property: The maximum CPF savings allowed to be used for the financing the property, excluding the amount used for stamp duty and legal fees.

Refer to the CPF display guidelines.

Notice of Assessment (Basic, Latest Year)user.noa-basic

This refers to the taxpayer's total income after deducting allowable expenses and approved donations. Total income includes:

  • Trade
  • Employment
  • Rent
  • Interest

This field will only return:

  • 1 yearly assessable income and

  • the corresponding year value. The yearly assessable income will be the latest available income up to the last 2 Years of Assessments. If the subscriber does not have any assessment record for up to 2 back years, Myinfo will return the following:

    • Assessable Income= 'NA' or '-'
    • Year Assessed='NA'.

To note:

  • Assessable Income details is only available for finalised assessment. Thus, income information will not be available if the subscriber has a Default Assessment (e.g. taxpayers who have not submitted their tax return).
  • This may not be applicable for foreigners depending on their tax residency. For example, in the case of double tax treaties with other countries, foreigner may not need to pay Singapore tax.
Notice of Assessment (Detailed, Latest Year)user.noa

Similar to 'Notice of Assessment (Basic, Latest Year)' data field, including the following income breakdown

  • Employment
  • Trade
  • Rent
  • Interest

Additional details in this data field:

  • Tax clearance : Indicator will be 'Y' for scenario where non-Singapore Citizen employee that ceases employment in Singapore, and goes on an overseas posting or plans to leave Singapore for more than three months. Only need to display this field if the value = 'Y'.
  • Tax Category : Type of Income Tax Bill.
    Refer to IRAS tax assessment for details.
Notice of Assessment (Detailed, Last 2 Years)user.noahistorySimilar to 'Notice of Assessment (Basic, Latest Year)' data field, but for the last 2 years instead.
Notice of Assessment (Basic, Last 2 Years)user.noahistory-basicSimilar to 'Notice of Assessment (Basic, Latest Year)' data field, but for the last 2 years instead.
Ownership of Private Residential Propertyuser.ownerprivate

This refers to the ownership of private residential property.

Note that this does not include shophouses which are assessed as commercial properties.

This field will be 'Y', if the corresponding NRIC/FIN, in IRAS records, is a primarily, secondary or CC owner of an active private residential property and is required to pay property tax. Otherwise will be 'N'.

Where the NRIC/FIN is not found in IRAS records, it will be returned as 'NA'.

## Employment
NameScopeDescription
CPF Employersuser.cpfemployers

Employer Name for the CPF Contribution. Includes contribution month/year.

Only Contribution(s) related to employment will be provided. Other contributions, such as self-employed or government top-ups, are presently excluded.

CPF will return the contributions received (or paid on) in the past 15 months up to the preceding month. Note that a member could have multiple contributions per month from the same employer.

Name of Employeruser.employment

This refers to the employment sector of a FIN holder.

Note that this only applies to a FIN holder with a valid pass issued by MOM.

# Corppass Scopes Myinfo Business Corppass scopes provide access to information about the **transacting user’s Corppass account**. These scopes are only available to [Myinfo Business applications](/products/myinfo-business). The corresponding data is returned via the [Userinfo Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint) under `corppass_info`. Refer to [Corppass Info](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint/corppass-info) for more details. {% hint style="info" %} In the Singpass Developer Portal, Corppass scopes can be found under the Person scopes tab when configuring your Myinfo Business application. {% endhint %}
NameScopeDescription
Corppass Registered Emailcorppass.email

Corppass registered email address of the transacting user’s Corppass account.

Source: Corppass

# Migration Guides # Migration Guide: Legacy to FAPI 2.0 This guide assists partners in transitioning existing integrations from the [Corppass Authorization API (Legacy)](/technical-specifications/corppass-authorization-api-legacy) to the new **FAPI 2.0‑compliant Authorization API**. The new implementation strengthens security by adopting the **Financial-grade API (FAPI) 2.0 Security Profile**, built on OAuth 2.0 and OpenID Connect. ## Why Migrate? FAPI 2.0 introduces enhanced security mechanisms, mandated flows, and updated token structures that improve confidentiality, integrity, and replay protection compared to the Legacy Security Profile. These changes align with global security best practices and provide long‑term reliability. Legacy Security Profile will be deprecated, and partners must migrate to continue using the service. *** ## Key Changes See [Changelog: FAPI 2.0 Launch](/technical-specifications/corppass-authorization-api-fapi-2.0/changelog/corppass-authorization-api-fapi-2.0-launch)
FeatureLegacy Security ProfileFAPI 2.0 Security Profile
Enhanced SecurityStandard authorization code flow

Enhanced security with

Authorization FlowAuthorization parameters provided via front-channel (params in URL).

Authorization parameters provided via back-channel Pushed Authorization Request (PAR) endpoint.

The requests are also contextualised with new parameters for Corppass Login applications:

  • authentication_context_type
  • authentication_context_message

Refer to Pushed Authorization Request for more details.

Authorization Request Parameters

Authorization Endpoint:

  • client_id
  • code_challenge
  • code_challenge_method
  • response_type
  • redirect_uri
  • scope
  • state
  • nonce

Pushed Authorization Request:

  • client_id
  • client_assertion
  • client_assertion_type
  • code_challenge
  • code_challenge_method
  • response_type
  • redirect_uri
  • scope
  • state
  • nonce
  • acr_values
  • dpop_jkt

Authorization Endpoint:

  • client_id
  • request_uri

Refer to Pushed Authorization Request and Authorization Endpoint for more details.

ID Token

Flat, custom structure.

  • sub encapsulating user information.
  • entityInfo encapsulating entity information.
  • userInfo encapsulating acting user's information.

Structured, hierarchical structure.

  • sub representing subject (entity / user) identifier.
  • sub_attributes encapsulating profile information about the subject (entity on primary / root level, user on actor level).
  • act encapsulating information about the subject acting on behalf of the primary subject.

Refer to ID Token section for more details.

Userinfo Endpoint

(Additional User / Authorization Data Retrieval)

Endpoint: /authorization-info.

Returns PascalCase keys:

  • AuthInfo
  • TPAuthInfo

Format: JWS

Endpoint: /userinfo (Standard OIDC endpoint name)

Returns snake_case keys:

  • auth_info
  • tp_auth_info

Format: JWE

Refer to Userinfo Endpoint for more details.

Error HandlingLegacy / custom error formats.

Standardised OAuth 2.0 Errors.

  • error
  • error_description
  • state
ScopesStandard scopes (openid, authinfo, tpauthinfo)

Finer-grained scopes (e.g., entity.identity, user.identity, user.name), allowing for more precise data access control.

Refer to Scopes section for more details.

*** ## Migration Steps ### Step 1: Review Client Configuration & Scopes Review your client configuration on the [**Corppass Developer Portal**](https://developer.corppass.gov.sg/) to accommodate new mandatory parameters and scope changes. 1. **Review Authentication Context Type:**\ FAPI 2.0 introduces `authentication_context_type` as a mandatory parameter to define the transaction context. 1. **Configuration:** Your client profile now includes a list of "Supported Authentication Context Types". Currently, only `APP_AUTHENTICATION_DEFAULT` is supported. This value will be automatically backfilled for all existing clients. 2. **Constraint:** During an authorization request, you can only request a context type that is explicitly configured for your client. For now, you must use `APP_AUTHENTICATION_DEFAULT` value in your requests. Refer to [Authentication Context Parameters](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/1.-pushed-authorization-request-par-endpoint/authentication-context-parameters) section for more details.
2. **Review Scopes:**\ FAPI 2.0 introduces new finer-grained scopes. 1. **Configuration:** To ensure continuity, Corppass will automatically backfill your client profile with finer-grained FAPI 2.0 scopes corresponding to your legacy access. 2. **Review:** Audit the backfilled scopes in your client configuration. Remove any that provides access to data your application no longer needs. Refer to [Scopes](/technical-specifications/corppass-authorization-api-fapi-2.0/scopes) section for more details. 3. **Review OIDC Redirect URLs:**\ FAPI 2.0 now mandates the use of redirect URLs with `https` scheme. 1. **Configuration:** Make sure you have at least one usable redirect URL with `https` scheme configured. 2. **Constraint**: During an authorization request, you must provide a redirect URL with `https` scheme, or else you will not be allowed to initialise authorization on FAPI 2.0. ### Step 2: Retrieve new metadata from OpenID discovery endpoint The OpenID Connect Discovery URL remains the same as the Legacy API. 1. **New Endpoints Metadata:** Query the existing Discovery URL to retrieve updated provider metadata. Configure your application to use the new endpoint values found in the metadata: 1. `pushed_authorization_request_endpoint` (New: Required for PAR) 2. `userinfo_endpoint` (Replaces `/authorization-info`) Refer to [OpenID Discovery Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/0.-well-known-endpoints/openid-discovery-endpoint) for more details. ### Step 3: Authorization Request **Significant Change:** You can no longer construct the authorization URL directly in the browser. You need to implement **Pushed Authorization Request (PAR)**. 1. **Call the PAR Endpoint (`/request`):** 1. Initiate the flow via a *back-channel `POST` request*. 2. Include DPoP proof in the request. 3. Include the necessary OIDC parameters (e.g., `client_id`, `scope`, `redirect_uri`) along with the new mandatory fields (e.g., `client_assertion`, `code_challenge`, `authentication_context_type`). 4. Corppass returns a `request_uri` that references your payload. 2. **Browser Redirect to Authorization Endpoint (`/authorize`):** 1. Redirect the user to the Authorization Endpoint using only `client_id` and the returned `request_uri` returned in the previous step. 2. This replaces the Legacy method of exposing sensitive parameters directly in the browser URL. Refer to [Pushed Authorization Request (PAR) Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/1.-pushed-authorization-request-par-endpoint) for more details. ### Step 4: Token Exchange The Token Endpoint (`/token`) now enforces strict security proofs. 1. **Prepare the Request:** 1. **Mandatory Client Authentication:** Use `client_assertion` (Private Key JWT). 2. **Mandatory PKCE:** Include the `code_verifier` matching the `code_challenge` from PAR. 3. **Mandatory DPoP:** Include a `DPoP` HTTP header. The public key in this header will be bound to the resulting Access Token. 2. **Handle the Response:** 1. **Access Token:** Store the opaque token for subsequent API calls where needed. 1. Note: The token is sender-constrained; you must use the same DPoP private key from the request to sign the DPoP header when using this token later. 2. **ID Token:** Decrypt the JWE using your private encryption key to retrieve the signed payload, then validate the signature. See Step 5. Refer to [Token Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/3.-token-endpoint) for more details. ### Step 5: Decrypt & Map ID Token The ID Token is an Encrypted JWT (JWE). 1. **Decrypt:** Use your private encryption key (from Step 2) to decrypt the token. 2. **Validate:** Verify the signature of the decrypted payload using Corppass's public signing key. 3. **Map New Claims:** Update your parsing logic to the new hierarchical structure.
DataLegacy ClaimFAPI 2.0 Claim
Entity Details

entityInfo.*

{
  "entityInfo": {
    "CPEntID": "T09LL0001B",
    "CPEnt_TYPE": "UEN",
    "CPEnt_Status": "Registered",
    "CPNonUEN_Country": "",
    "CPNonUEN_RegNo": "",
    "CPNonUEN_Name": ""
  }
}

sub, sub_attributes.*

{
  "sub": "T09LL0001B",
  "sub_type": "entity",
  "sub_attributes": {
    "entity_type": "UEN",
    "entity_reg_number": "T09LL0001B",
    "entity_coi": "SG",
    "entity_name": "My Example Company",
    "entity_uen_status": "Registered"
  }
}
User Details

sub

{
  "sub": "s=S1234567P,uuid=0f14a2fc-09c2-4780-95f0-8c28347f2780,u=CP192,c=SG"
}

userInfo.*

{
  "userInfo":{
    "CPAccType": "User",
    "CPUID_FullName": "John Grisham",
    "ISSPHOLDER": "YES"
  }
}

act.*

{
  "act": {
    "sub": "0f14a2fc-09c2-4780-95f0-8c28347f2780",
    "sub_type": "user",
    "sub_attributes": {
      "account_type": "standard", 
      "identity_number": "S1234567P",
      "identity_coi": "SG",
      "name": "John Grisham"
    }
  }
}
Refer to [ID Token](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/3.-token-endpoint/id-token) section for more details. ### Step 6: Userinfo Endpoint This is applicable if your application fetches additional user / authorization data. 1. **Use the new userinfo URL** 1. In the legacy API, this was available on the `/authorization-info` endpoint. 2. In the FAPI 2.0 API, this is served on the `/userinfo` endpoint (the metadata retrieved in Step 2, under `userinfo_endpoint`). 2. **Update Authorization header prefix to be DPoP instead of Bearer** 1. In the legacy API, the Authorization header would have been sent as a bearer token: ``` Authorization: Bearer ``` 2. In the FAPI 2.0 API, this needs to be sent with a `DPoP` prefix: ``` Authorization: DPoP ``` 3. **Handle new response format** 1. Update your JSON parser to handle snake\_case keys (e.g., `auth_info` instead of `AuthInfo`). 2. Since the response is now returned as a JWE, you must decrypt the payload using your registered private key before processing the claims. Refer to [Userinfo Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint) for more details. ### Step 7: Error Handling Ensure your application handles standard OAuth 2.0 error parameters (`error`, `error_description`, `state`): 1. **Handle Redirect URI:** Error query parameters on the callback URL (e.g., `https://client.com/cb?error=access_denied&error_description=...`) 2. **Handle API Response:** JSON bodies for `/request`, `/token` , or `userinfo` failures. Refer to the respective endpoints for more details. # Migration Guide: Myinfo Business v1/v2 to v3 (FAPI 2.0) This guide assists partners in transitioning existing integrations from Myinfo Business v2 (Legacy) to Myinfo Business v3. Myinfo Business v3 is built on the [Corppass Authorization API (FAPI 2.0)](/technical-specifications/corppass-authorization-api-fapi-2.0), which adopts the Financial-grade API (FAPI) 2.0 Security Profile based on OAuth 2.0 and OpenID Connect. ## Why Migrate? FAPI 2.0 introduces enhanced security mechanisms, mandated flows, and updated token structures that improve confidentiality, integrity, and replay protection compared to the Legacy APIs. These changes align with global security best practices and provide long‑term reliability. All legacy Myinfo Business v1/v2 applications will be deprecated, and partners must migrate to continue using the service. *** ## Key Changes
FeatureMyinfo Business (v1/v2)Myinfo Business (v3) (FAPI 2.0)
API Endpoints

Legacy API endpoints with base URL:

  • Test: https://test.api.myinfo.gov.sg/biz/[v1|v2]
  • Production: https://api.myinfo.gov.sg/biz/[v1|v2]

Legacy endpoints:

  • Authorization Endpoint (/authorise)
  • Token Endpoint (/token)
  • Entity-Person Endpoint (/entity-person/{uen}/{uuid})

Different set of API endpoints with base URL:

  • Staging: https://stg-id.corppass.gov.sg
  • Production: https://id.corppass.gov.sg

Standard OIDC / FAPI 2.0 endpoints:

  • Well-known Endpoints (/.well-known/openid-configuration) - where the following endpoints are dynamically obtained
  • Pushed Authorization Request Endpoint
  • Authorization Endpoint
  • Token Endpoint
  • Userinfo Endpoint

Refer to Integration Guide for more details.

Enhanced SecurityStandard authorization code flow

Enhanced security with

Authorization FlowAuthorization parameters provided via front-channel (params in URL).

Authorization parameters provided via back-channel Pushed Authorization Request (PAR) endpoint.

Refer to Pushed Authorization Request for more details.

Authorization Request Parameters

Authorization Endpoint:

  • client_id
  • authmode
  • purpose
  • response_type
  • redirect_uri
  • attributes
  • state

Pushed Authorization Request:

  • client_id
  • client_assertion
  • client_assertion_type
  • code_challenge
  • code_challenge_method
  • response_type
  • redirect_uri
  • scope
  • state
  • nonce
  • acr_values
  • dpop_jkt

Authorization Endpoint:

  • client_id
  • request_uri

Refer to Pushed Authorization Request and Authorization Endpoint for more details.

Token Request Parameters

Token Endpoint:

  • code
  • redirect_uri
  • grant_type
  • client_id
  • client_secret
  • state

Token Endpoint:

  • code
  • redirect_uri
  • grant_type
  • client_id
  • client_assertion_type
  • client_assertion
  • code_verifier

Refer to Token Endpoint for more details.

Data Retrieval Endpoint

Endpoint: /entity-person/{uen}/{uuid}

uen and uuid are obtained from the sub (uen_uuid) value in the decoded access_token.

Legacy payload structure within:

  • entity
  • person

Endpoint: /userinfo (Standard OIDC endpoint)

No longer required to provide uen and uuid values as these are handled through the Standard OIDC flow. Access Token is to be treated as opaque string.

Updated payload structure within:

  • entity_info
  • person_info
  • corppass_info

Refer to Userinfo Endpoint for more details.

Error Handling

Legacy / custom error formats.

  • API response

    • code
    • message

  • Redirect URI

    • error
    • error_description
    • state

Standardised OAuth 2.0 Errors.

  • error
  • error_description
  • state
ScopesCategory-based entity scopes and fine-grained person scopes (basic-profile, financials, capitals, name, uinfin)

Fine-grained scopes across entity and person scopes (e.g., entity.basic_profile.name, entity.basic_profile.uen_status, user.name), allowing for more precise data access control.

Refer to Myinfo Business Scopes for more details.

*** ## Scope Changes ### Entity Information Updates * Renamed `uen` to `registration_number`. This change affects basic profile, entity appointments, and shareholders. * Replaced `entity-status` with `uen-status` (support for `entity-status` has been dropped). * Dropped the `ownership` field from basic profile. * Dropped `primary user described activity` and `secondary user described-activity`. * Introduced a new `id_type` (identification type) field for individual appointments and shareholders. * Dropped support for `corppass-email` and `corppass-mobileno` on individual appointments and shareholders. * Deprecated the Government contracts category (`gov-contracts`). Please expand the section below for a detailed mapping of the entity object changes
Entity Object Migration Mapping | Object under v1/v2 | Object under v3 | Changes made | | ----------------------------------------------------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | `entity.basic-profile.company-type` | `entity_info.basic_profile.company_type` | | | `entity.basic-profile.business-constitution` | `entity_info.basic_profile.constitution` | Renamed | | `entity.basic-profile.country-of-incorporation` | `entity_info.basic_profile.country_of_incorporation` | | | `entity.basic-profile.business-expiry-date` | `entity_info.basic_profile.expiry_date` | Renamed | | `entity.basic-profile.entity-name` | `entity_info.basic_profile.name` | Renamed | | `entity.basic-profile.primary-activity` | `entity_info.basic_profile.primary_activity` | | | `entity.basic-profile.registration-date` | `entity_info.basic_profile.registration_date` | | | `entity.basic-profile.uen` | `entity_info.basic_profile.registration_number` | Renamed | | `entity.basic-profile.secondary-activity` | `entity_info.basic_profile.secondary_activity` | | | `entity.basic-profile.entity-type` | `entity_info.basic_profile.type` | Renamed | | `entity.basic-profile.entity-status` | |

Dropped.
Please use entity.basic\_profile.uen\_status instead.

| | | `entity_info.basic_profile.uen_status` | New | | `entity.basic-profile.ownership` | | Dropped | | `entity.basic-profile.primary-user-described-activity` | | Dropped | | `entity.basic-profile.secondary-user-described-activity` | | Dropped | | `entity.addresses.address-list` | `entity_info.address` | Renamed, nesting changed | | `entity.previous-names.previous-names-list.history-name` | `entity_info.history.previous_names.previous_name` | Renamed, nesting changed | | `entity.previous-names.previous-names-list.history-name-effective-date` | `entity_info.history.previous_names.previous_name_effective_date` | Renamed, nesting changed | | `entity.previous-uens.previous-uens-list.previous-uen` | `entity_info.history.previous_registration_numbers.previous_registration_number` | Renamed, nesting changed | | `entity.appointments.appointments-list.appointment-date` | `entity_info.appointments.appointment_date` | Nesting changed | | `entity.appointments.appointments-list.position` | `entity_info.appointments.position` | Nesting changed | | `entity.appointments.appointments-list.category` | `entity_info.appointments.category` | Nesting changed | | | `entity_info.appointments.designation` | New | | `entity.appointments.appointments-list.entity-reference.entity-name` | `entity_info.appointments.entity_appointment.name` | Renamed, nesting changed | | `entity.appointments.appointments-list.entity-reference.uen` | `entity_info.appointments.entity_appointment.registration_number` | Renamed, nesting changed | | `entity.appointments.appointments-list.entity-reference.entity-type` | `entity_info.appointments.entity_appointment.type` | Renamed, nesting changed | | `entity.appointments.appointments-list.person-reference.idno` | `entity_info.appointments.individual_appointment.id_number` | Renamed, nesting changed | | | `entity_info.appointments.individual_appointment.id_type` | New | | `entity.appointments.appointments-list.person-reference.person-name` | `entity_info.appointments.individual_appointment.name` | Renamed, nesting changed | | `entity.appointments.appointments-list.person-reference.nationality` | `entity_info.appointments.individual_appointment.nationality` | Nesting changed | | `entity.appointments.appointments-list.corppass-email` | | Dropped | | `entity.appointments.appointments-list.corppass-mobileno` | | Dropped | | `entity.shareholders.shareholders-list.entity-reference.entity-name` | `entity_info.shareholders.entity_shareholder.name` | Renamed, nesting changed | | `entity.shareholders.shareholders-list.entity-reference.uen` | `entity_info.shareholders.entity_shareholder.registration_number` | Renamed, nesting changed | | `entity.shareholders.shareholders-list.entity-reference.entity-type` | `entity_info.shareholders.entity_shareholder.type` | Renamed, nesting changed | | `entity.shareholders.shareholders-list.person-reference.idno` | `entity_info.shareholders.individual_shareholder.id_number` | Renamed, nesting changed | | | `entity_info.shareholders.individual_shareholder.id_type` | New | | `entity.shareholders.shareholders-list.person-reference.person-name` | `entity_info.shareholders.individual_shareholder.name` | Renamed, nesting changed | | `entity.shareholders.shareholders-list.person-reference.nationality` | `entity_info.shareholders.individual_shareholder.nationality` | Nesting changed | | `entity.shareholders.shareholders-list.allocation` | `entity_info.shareholders.allocation` | Nesting changed | | `entity.shareholders.shareholders-list.category` | `entity_info.shareholders.category` | Nesting changed | | `entity.shareholders.shareholders-list.currency` | `entity_info.shareholders.currency` | Nesting changed | | `entity.shareholders.shareholders-list.share-type` | `entity_info.shareholders.share_type` | Nesting changed | | `entity.shareholders.shareholders-list.corppass-email` | | Dropped | | `entity.shareholders.shareholders-list.corppass-mobileno` | | Dropped | | `entity.capitals.capitals-list.currency` | `entity_info.capitals.currency` | Nesting changed | | `entity.capitals.capitals-list.issued-capital-amount` | `entity_info.capitals.issued_amount` | Renamed, nesting changed | | `entity.capitals.capitals-list.paid-up-capital-amount` | `entity_info.capitals.paid_up_amount` | Renamed, nesting changed | | `entity.capitals.capitals-list.share-allotted-amount` | `entity_info.capitals.share_allotted_number` | Nesting changed | | `entity.capitals.capitals-list.capital-type` | `entity_info.capitals.share_type` | Renamed, nesting changed | | `entity.financials.highlights.is-audited` | `entity_info.financials.is_audited` | Nesting changed | | `entity.financials.highlights.company-profit-loss-after-tax` | `entity_info.financials.company_financial.profit_loss_after_tax` | Nesting changed | | `entity.financials.highlights.company-profit-loss-before-tax` | `entity_info.financials.company_financial.profit_loss_before_tax` | Nesting changed | | `entity.financials.highlights.company-revenue` | `entity_info.financials.company_financial.revenue` | Renamed, nesting changed | | `entity.financials.highlights.currency` | `entity_info.financials.currency` | Nesting changed | | `entity.financials.highlights.current-period-end-date` | `entity_info.financials.current_period_end_date` | Nesting changed | | `entity.financials.highlights.current-period-start-date` | `entity_info.financials.current_period_start_date` | Nesting changed | | `entity.financials.highlights.group-profit-loss-after-tax` | `entity_info.financials.group_financial.profit_loss_after_tax` | Nesting changed | | `entity.financials.highlights.group-profit-loss-before-tax` | `entity_info.financials.group_financial.profit_loss_before_tax` | Nesting changed | | `entity.financials.highlights.group-revenue` | `entity_info.financials.group_financial.revenue` | Renamed, nesting changed | | `entity.financials.highlights.group-capital-paid-up-capital-amount` | `entity_info.financials.group_financial.share_capital` | Renamed, nesting changed | | `entity.grants.grants-list.development-category` | `entity_info.grants.development_category` | Nesting changed | | `entity.grants.grants-list.functional-area` | `entity_info.grants.functional_area` | Nesting changed | | `entity.grants.grants-list.submitted-date` | `entity_info.grants.submitted_on_date` | Renamed, nesting changed | | `entity.grants.grants-list.approved-amount` | `entity_info.grants.approved_amount` | Nesting changed | | `entity.grants.grants-list.last-updated-date` | `entity_info.grants.last_update_date` | Nesting changed | | `entity.grants.grants-list.grant-status` | `entity_info.grants.status` | Renamed, nesting changed | | `entity.grants.grants-list.grant-type` | `entity_info.grants.type` | Renamed, nesting changed | | `entity.licences.licences-list.issuance-agency` | `entity_info.licences.issuance_agency` | Nesting changed | | `entity.licences.licences-list.expiry-date` | `entity_info.licences.expiry_date` | Nesting changed | | `entity.licences.licences-list.issue-date` | `entity_info.licences.issue_date` | Nesting changed | | `entity.licences.licences-list.licence-name` | `entity_info.licences.licence_name` | Nesting changed | | `entity.licences.licences-list.licence-number` | `entity_info.licences.licence_number` | Nesting changed | | `entity.builders.builders-list.licence` | `entity_info.builders.licence` | Nesting changed | | `entity.builders.builders-list.licence-expiry-date` | `entity_info.builders.licence_expiry_date` | Nesting changed | | `entity.contractors.contractors-list.registration-expiry-date` | `entity_info.contractors.crs_expiry_date` | Renamed, nesting changed | | `entity.contractors.contractors-list.workhead` | `entity_info.contractors.workhead` | Nesting changed | | `entity.contractors.contractors-list.workhead-financial-grade` | `entity_info.contractors.workhead_financial_grade` |

Nesting changed

From code and desc to value only

| | `gov-contracts.*` | | Entire category has been dropped |
### Person Information Updates * Dropped support for the following CPF-related information: * `cpfhomeprotectionscheme` * `cpfdependantprotectionscheme` * `cpfmedishieldlife` * `cpfrstucurrentyeartaxrelief` * `cpfrstuselftopupamount` * `cpflife` * `cpfmonthlypayouts` * Curated a focused list of person scopes tailored for business use cases. If you require a scope that is not currently listed, please submit a request at [partnersupport.singpass.gov.sg](http://partnersupport.singpass.gov.sg/). *** ## Migration Steps ### Step 1: Create Myinfo Business v3 Application Create a new Myinfo Business v3 application on the [Singpass Developer Portal (SDP)](https://developer.singpass.gov.sg/). Existing Client ID / App ID cannot be used in the new version as they are not interchangeable. Refer to [Getting Started](/products/myinfo-business/getting-started) guide for step-by-step instructions on creating and configuring your application. ### Step 2: Implement Myinfo Business v3 Integration Myinfo Business v3 is built on the [Corppass Authorization API (FAPI 2.0)](/technical-specifications/corppass-authorization-api-fapi-2.0) and introduces significant changes to the authorization flow, security requirements, and data handling. As the APIs and integration patterns differ substantially from v1/v2, partners are required to implement the integration based on the latest specifications. Refer to [Integration Guide](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide) for full implementation details. # Changelog {% updates format="full" %} {% update date="2026-05-18" %} ## Myinfo Business Support New Myinfo Business-specific scopes and corresponding response structures are introduced to support retrieval of entity and user data. New Myinfo Business integrations must be onboarded as Myinfo Business v3 applications, integrating with the Corppass Authorization API (FAPI 2.0). [Refer to getting started guide](/products/myinfo-business/getting-started) Existing services must migrate by 31 May 2027, after which legacy versions will be deprecated. [Refer to migration guide](/technical-specifications/corppass-authorization-api-fapi-2.0/migration-guides/migration-guide-myinfo-business-v1-v2-to-v3-fapi-2.0) [>> More details](/technical-specifications/corppass-authorization-api-fapi-2.0/changelog/myinfo-business-support) {% endupdate %} {% update date="2026-02-23" %} ## Corppass Authorization API (FAPI 2.0) Launch The new [Corppass Authorization API (FAPI 2.0)](/technical-specifications/corppass-authorization-api-fapi-2.0) is now available, introducing enhanced security mechanisms, mandatory flows (e.g. PAR, PKCE, DPoP), updated token structures, and finer-grained scopes. These changes replace the legacy security profile and align with modern security standards. New services must use FAPI 2.0. Existing services onboarded before 23 March 2026 must migrate by 31 March 2027, as the legacy security profile will be deprecated on 1 April 2027. [Refer to migration guide](/technical-specifications/corppass-authorization-api-fapi-2.0/migration-guides/migration-guide-legacy-to-fapi-2.0) [>> More details](/technical-specifications/corppass-authorization-api-fapi-2.0/changelog/corppass-authorization-api-fapi-2.0-launch) {% endupdate %} {% endupdates %} # Myinfo Business Support May 18, 2026 Myinfo Business support is now available on [Corppass Authorization API (FAPI 2.0)](/technical-specifications/corppass-authorization-api-fapi-2.0). [Refer to getting started guide](/products/myinfo-business/getting-started) New Myinfo Business-specific scopes and corresponding response structures are introduced to support retrieval of entity and user data. New Myinfo Business integrations must be onboarded as Myinfo Business v3 applications, integrating with the Corppass Authorization API (FAPI 2.0). Existing services must migrate by 31 May 2027, after which legacy versions will be deprecated. [Refer to migration guide](/technical-specifications/corppass-authorization-api-fapi-2.0/migration-guides/migration-guide-myinfo-business-v1-v2-to-v3-fapi-2.0) ### Key Changes #### Scopes * New scopes are introduced to support access to Myinfo Business data: * Entity scopes (e.g., `entity.basic_profile.*`, `entity.address`, `entity.appointments.*`) * Person scopes (e.g., `user.employmentsector`, `user.passtype`) * Corppass scopes (e.g., `corppass.email`) * The scopes are only available to [Myinfo Business](/products/myinfo-business) applications. * Refer to [Myinfo Business Scopes](/technical-specifications/corppass-authorization-api-fapi-2.0/scopes/myinfo-business-scopes) for more details. #### Userinfo Endpoint * Additional Myinfo Business data available on the Userinfo Endpoint: * `entity_info` for business-related information about the entity the user is transacting on behalf of. * `person_info` for personal information about the user acting on behalf of the entity. * `corppass_info` for information about the transacting user's Corppass account. * Refer to [Userinfo Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint) for more details. # Corppass Authorization API (FAPI 2.0) Launch February 23, 2026 [Corppass Authorization API (FAPI 2.0)](/technical-specifications/corppass-authorization-api-fapi-2.0) is now available for integration. It adopts the Financial-grade API (FAPI) 2.0 Security Profile, built on OAuth 2.0 and OpenID Connect, to provide stronger authentication and authorisation through enhanced security controls and standardised flows. New services must use FAPI 2.0. Existing services onboarded before 23 March 2026 must migrate by 31 March 2027, as the legacy security profile will be deprecated on 1 April 2027. [Refer to migration guide](/technical-specifications/corppass-authorization-api-fapi-2.0/migration-guides/migration-guide-legacy-to-fapi-2.0) ### Key Changes #### Authorization Flow & Enhanced Security **Pushed Authorization Request (PAR) Flow** * All RPs **must** implement the PAR flow for enhanced security. * The authorization request is initiated via the backchannel `/request` endpoint (PAR). * Refer to [Pushed Authorization Request](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/1.-pushed-authorization-request-par-endpoint) for more details. **Proof Key of Code Exchange (PKCE)** * PKCE is **mandatory** for all RPs performing the PAR flow for enhanced security. This provides additional protection against authorization code interception. * Refer to [Proof Key of Code Exchange](/technical-specifications/technical-concepts/proof-key-of-code-exchange-pkce) for more details. **Demonstrating Proof of Possession (DPoP)** * A DPoP Proof JWT **must** be included in PAR request, Token request, and all subsequent calls to protected resource endpoints (e.g., Userinfo Endpoint). * Refer to [Demonstrating Proof of Possession (DPoP)](/technical-specifications/technical-concepts/demonstrating-proof-of-possession-dpop) for more details. **Stricter TTL requirements** * Authorization code expiry is reduced from 10 min to **1 min**. * Refer to [Token Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/3.-token-endpoint) for more details. **Stricter client assertion requirements** * Maximum allowed lifespan for client assertion tokens is now **2 mins**. * Client assertions can no longer be reused. All client assertions must include `jti` claim to prevent client assertion replay attacks. * Refer to [Client Assertion JWT](/technical-specifications/technical-concepts/client-assertion-jwt) for more details. #### Authentication Context Parameters * Two new parameters are introduced to support contextualising authentication requests for Corppass Login applications: * `authentication_context_type` (Mandatory) * `authentication_context_message` (Optional) * See [Authentication Context Parameters](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/1.-pushed-authorization-request-par-endpoint/authentication-context-parameters) for more details. #### Scopes * New finer-grained scopes are introduced to provide more control over requested authorization: * Authorization scopes * `authinfo` * `tpauthinfo` * Entity scopes * `entity.identity` * `entity.basic_profile.name` * `entity.basic_profile.uen_status` * User scopes * `user.identity` * `user.name` * Refer to [Scopes](/technical-specifications/corppass-authorization-api-fapi-2.0/scopes) for more details. #### ID Token and Userinfo Changes **Changes to ID Token Structure** * Adopts a nested structure for better organisation and standard alignment where possible. * `sub` claim value now references the subject identifier directly. * New claims introduced: * `sub_type` * `sub_attributes` * `act` * Deprecated claims * `entityInfo` -> replaced by `sub_attributes` * `userInfo` -> replaced by `act.sub_attributes` * `email` (formerly with restricted access in beta release) * `email_verified` (formerly with restricted access in beta release) * Refer to [ID Token](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/3.-token-endpoint/id-token) for more details. **Userinfo Endpoint** * The Authorization Info Endpoint (`/authorization-info`) is replaced by the Userinfo Endpoint (`/userinfo`). * The response is returned as **JWE (JSON Web Encryption)**. * Response payload structure updated: * `AuthInfo` claim -> `auth_info` * `TPAuthInfo` claim -> `tp_auth_info` * Refer to [Userinfo Endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint) for more details. #### Error Handling * The API returns standardised OAuth 2.0 error responses across all endpoints, with parameters: `error`, `error_description`, and `state` (where available). * API Calls (Back-channel): Direct API requests (e.g., PAR, Token, Userinfo endpoints) return these error parameters in the JSON response body with the appropriate HTTP status code. * Authorization Redirects (Front-channel): If a failure occurs during the authorization flow, the user's browser will be redirected to your `redirect_uri` with these parameters appended as query strings. # Corppass Authorization API (Legacy) {% hint style="warning" %} **Action Required: Upgrade to FAPI 2.0 by 31 March 2027** FAPI 2.0 is a high-assurance security profile built on OAuth 2.0 and OpenID Connect, that strengthens authentication and authorisation. [Refer to documentation](/technical-specifications/corppass-authorization-api-fapi-2.0) \ **What this means for partners** * New services must use FAPI 2.0 to meet the latest security standards. * All existing services onboarded before 23 March 2026 must migrate to FAPI 2.0 by 31 March 2027, as the legacy security profile will be deprecated on 1 April 2027. To ensure continuity of service, we encourage planning and completing migration early. [Refer to migration guide](/technical-specifications/corppass-authorization-api-fapi-2.0/migration-guides/migration-guide-legacy-to-fapi-2.0) * Submit your migration plan (current progress and target date) so we can support your transition and avoid service disruption. [Submit migration plan](https://go.gov.sg/cp-fapi-migration-plan) {% endhint %} This technical specification outlines the web-based Application Programming Interfaces (APIs) designed for use by Relying Parties (RPs) and clients. It specifies the APIs that RPs must invoke to facilitate OpenID Connect (OIDC) authentication and retrieve authorization information for Corppass users. The following diagram illustrates the OIDC flow between the RP and Corppass, detailing the interactions required to authenticate users and access their authorization information:
All RPs should follow these steps, as illustrated in the above diagram. A short summary of the diagram: 1. **Discover OpenID Provider Configuration** * Retrieve the details of the OpenID Provider by querying the OpenID Discovery endpoint. Refer to the [OpenID Discovery Endpoint](/technical-specifications/corppass-authorization-api-legacy/endpoints/well-known-endpoints/openid-discovery-endpoint) section. 2. **Initiate Authorization Request** * Send an authorization request to the Corppass Authorization Endpoint to obtain an authorization code. Refer to the [Authorization Endpoint](/technical-specifications/corppass-authorization-api-legacy/endpoints/authorization-endpoint) section. 3. **User Authentication** * The user will be prompted to log in with Singpass and authenticate using their Singpass credentials. 4. **Token Exchange** * Exchange the authorization code and client assertion at the Token Endpoint to obtain the ID token and access token. Refer to the [Token Endpoint](/technical-specifications/corppass-authorization-api-legacy/endpoints/token-endpoint) section. 5. **ID Token Encryption** * Corppass retrieves the RP's encryption public key from the client’s JWKS during the token issuance process. Refer to the [Client JWKS](/technical-specifications/technical-concepts/client-jwks) section. 6. **ID Token Signature Validation** * The RP retrieves Corppass's signing public key from the JWKS endpoint to validate the signature of the ID token. Refer to the [JWKS Endpoint](/technical-specifications/corppass-authorization-api-legacy/endpoints/well-known-endpoints/jwks-endpoint) section. 7. **Retrieve Authorization Information** * Use the access token to query the Authorization Info Endpoint and retrieve the Corppass user’s authorization details. Refer to the [Authorization Info Endpoint](/technical-specifications/corppass-authorization-api-legacy/endpoints/authorization-info-endpoint) section # Staging and Production URLs The domains used in sample requests below may differ from those in your environment. Choose the appropriate domain from the table below based on your testing or production requirements. {% hint style="warning" %} **NO** certificate pinning or dependencies should be implemented on the TLS certificates for Corppass domains. **Corppass reserves the right to update or rotate its TLS certificates without prior notice to RPs.** {% endhint %} | Endpoint | Access Mechanism | Staging URL | Production URL | | --------------------------- | ------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------- | | OpenID Discovery Endpoint | Public TLS | `https://stg-id.corppass.gov.sg/.well-known/openid-configuration` | `https://id.corppass.gov.sg/.well-known/openid-configuration` | | JWKS Endpoint | Public TLS | `https://stg-id.corppass.gov.sg/.well-known/keys` | `https://id.corppass.gov.sg/.well-known/keys` | | Authorization Endpoint | Public TLS | `https://stg-id.corppass.gov.sg/mga/sps/oauth/oauth20/authorize` | `https://id.corppass.gov.sg/mga/sps/oauth/oauth20/authorize` | | Token Endpoint | Public TLS w/ Client Assertions | `https://stg-id.corppass.gov.sg/mga/sps/oauth/oauth20/token` | `https://id.corppass.gov.sg/mga/sps/oauth/oauth20/token` | | Authorization Info endpoint | Public TLS w/ Access Token | `https://stg-id.corppass.gov.sg/authorization-info` | `https://id.corppass.gov.sg/authorization-info` | # Endpoints # Authorization Endpoint Corppass supports OAuth 2.0 authorisation flow, specifically: * **Authorization Code Flow with PKCE** The flow returns: * **Authorization Code** * **State Parameter** Refer to the following section for further details: {% content-ref url="/pages/wci417aokVatVmnkvW9h" %} [Authorization Code with Proof Key of Code Exchange (PKCE) Flow](/technical-specifications/corppass-authorization-api-legacy/endpoints/authorization-endpoint/authorization-code-with-proof-key-of-code-exchange-pkce-flow) {% endcontent-ref %} # Authorization Code with Proof Key of Code Exchange (PKCE) Flow ``` GET /mga/sps/oauth/oauth20/authorize  ``` This endpoint is used to initiate the OpenID Connect (OIDC) authentication flow and obtain an authorization code, known as the Authorization Code flow. The authorization code can later be exchanged with Corppass at the token endpoint to retrieve an ID token and an access token. After the user successfully authenticates with Singpass, the authorization code is returned to the user agent as part of a `302 Redirect` response to the Relying Party's specified `redirect_uri`. #### Request
Query ParameterRequiredDescription
scopeYesMust contain at least the openid scope. For a comprehensive list of valid scopes, refer to the Scopes Overview section. Unrecognised or unauthorised scopes will result in an error.
response_typeYesSpecifies the response processing flow. Currently, Corppass only supports code as a valid value.
client_idYesThe client identifier assigned to the Relying Party during onboarding with Corppass.
redirect_uriYesThe callback URL for receiving the authorization response. Must exactly match one of the RPs' registered callback URLs registered.
stateYesA client-provided value used to maintain state between the request and the callback. Helps to mitigate Cross-Site Request Forgery (CSRF, XSRF) attacks.
nonceYesA unique value provided by the RP that is returned in the ID Token. Used to prevent replay attacks and must be validated by the RP.
esrvcIDNoApplicable only to specific RPs authorized by Corppass.
code_challengeYesThe hashed value generated from the code verifier. Refer to Proof Key of Code Exchange for more details about the concept.
code_challenge_methodYesThe code verifier transformation method. Currently, Corppass only supports S256 as a valid value.
#### Response
Query ParameterDescription
codeThe authorization code returned by the authorization server in the callback URL. This one-time code must be used by the Relying Party to invoke the token endpoint and retrieve the user's ID token and access token. Learn more.
state

The state parameter returned as-is to help the client maintain state between the request and the callback.

It is typically employed to mitigate Cross-Site Request Forgery (CSRF, XSRF) attacks. Learn more.

issThe issuer identifier of the Corppass authorization server (See the issuer field in the OpenID Discovery Endpoint). Both success and failure response redirects will contain this parameter. For security, it is recommended that clients verify this value against the expected Corppass issuer before acting on the response.
# Token Endpoint ``` POST /mga/sps/oauth/oauth20/token ``` This endpoint allows the client to exchange an authorization code for an ID token and an access token. * The ID token is a JWT that includes user information in the `sub` claim and is signed by Corppass. Relying Parties (RPs) can verify the JWT's signature using the public keys available at the Corppass JWKS endpoint. * The Access Token is a signed JWS intended for the Corppass resource server (e.g. `/authorization-info`). ### Supported Grant Types Grant types define the method by which a client obtains tokens from the authorization server. For the Open ID Connect (OIDC) authentication flow, Corppass supports the following grant types:
Grant TypeDescription
authorization_codeUsed to securely exchange an authorization code for an ID token and access token. Requires prior user authentication and is suitable for confidential clients. Refer to Section 3.1 of the OIDC Core Specification for more details on this grant.
#### Authorization Code Grant The `authorization_code` grant type allows the client to exchange an authorization code (provided to the client after the user is authenticated) for an ID token and an access token. This grant is restricted to **confidential clients**, which must authenticate themselves using **Client Assertion JWT.** The client must include a JSON Web Token (JWT) in the token request body. Corppass will verify the JWT's signature using the public key provided in the JSON Web Key Set (JWKS) during client onboarding. #### Request Request Headers | Header | Value | | ------------ | ------------------------------------------------ | | Content-Type | application/x-www-form-urlencoded; charset=utf-8 | Request Body
FieldDescription
redirect_uriThe redirect URI used in the current authentication session.
grant_typeThe type of grant being requested. This must be set to authorization_code.
codeThe authorization code issued during the /authorize call.
client_assertion_typeMust be set to urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertionA JWT identifying the client. Refer to Client Assertion JWT section for more details about the JWT structure.
client_idThe client identifier assigned to the Relying Party during onboarding with Corppass.
code_verifierA cryptographic random string generated and is used to compare with code_challenge sent during the /authorize or /request call.
#### Response Successful Response Example 
{
    "access_token": "eyJraWQiOiJueGlKSk5OVnh4blRrVTJ3TDY1VEkyUGtJTElKT1VSU1RRU0FCTHVIMmtFIiwiYWxnIjoiRVMyNTYifQ.eyJleHAiOjE2MjQwODQ4MjMsImlhdCI6MTYyNDA4NDIyMywiaXNzIjoiaHR0cHM6Ly9jb3JwcGFzc3JwMDMiLCJhdWQiOiJ2T0lsaldWckd5Qk1LNmYzMVFZcSIsInNjb3BlIjpbImF1dGhpbmZvIiwidHBhdXRoaW5mbyJdfQ.jzzTSQw5w3B_88KgqzThrP237wYWkuuzBdRpHnT4iNoqWAjV8KsXDqwBgOnECsFBeshJXahMDswyqw6xlgTO9g",
    "scope": "openid",
    "id_token": "eyJraWQiOiJueGlKSk5OVnh4blRrVTJ3TDY1VEkyUGtJTElKT1VSU1RRU0FCTHVIMmtFIiwiYWxnIjoiRVMyNTYifQ.eyJlbnRpdHlJbmZvIjp7IkNQRW50SUQiOiJWQlIwMDAwMDQiLCJDUEVudF9UWVBFIjoiVUVOIiwiQ1BFbnRfU3RhdHVzIjoiUmVnaXN0ZXJlZCIsIkNQTm9uVUVOX0NvdW50cnkiOiIiLCJDUE5vblVFTl9SZWdObyI6IiIsIkNQTm9uVUVOX05hbWUiOiIifSwiYW1yIjpbInB3ZCJdLCJpYXQiOjE2MjQwODQyMjIsImlzcyI6Imh0dHBzOi8vY29ycHBhc3NycDAzIiwic3ViIjoicz1udWxsLHU9YW1pdGVzaCxjPW51bGwiLCJhdF9oYXNoIjoiMncxWjlBNW9qZExic2hSLUIwbFV4QSIsImV4cCI6MTYyNDA4NzgyMiwiYXVkIjoidk9JbGpXVnJHeUJNSzZmMzFRWXEifQ.lwTieBCXxOHMtKFkpLZDarzGe5QsZiFnZoWxVoSPLEzPhTABMgStGknzlf9m1hZiw6rCP_4InngFNLeh8DeztA",
    "token_type": "Bearer",
    "expires_in": 599
}
Response Body Fields
FieldRequiredTypeDescription
access_tokenYesJWSThe access token containing standard claims in JWS format, signed by Corppass. Refer to the Access Token section for more details.
scopeYesStringThe scopes granted for the issued tokens. This field may include openid along with other scopes requested during authorization.
id_tokenYesJWEThe ID token containing relevant claims in JWT format, signed by Corppass. Refer to the ID Token section for more details.
token_typeYesStringThe type of token issued. Currently, only Bearer is supported.
expires_inYesNumericThe remaining lifetime of the access token in seconds.
# ID Token Structure The ID Token contains both standard claims and Corppass-specific custom claims.
ClaimClaim ContentClaim Format
Standard ClaimsStandard claims such as iss , iat, exp, etc., as defined in the Section 5.1. of OIDC Core SpecificationString
Custom Claims

Corppass-specific claims providing details about the authenticated user:

  • userInfo: Includes Corppass user's personal information, such as full name and account type
  • entityInfo: Includes Corppass user's entity information, detailing entities the user is authorized for or selected during authorization (applicable when the user has access to multiple entities)
JavaScript Notation Object (JSON)
#### ID Token Format The ID Token is issued as a JWS encapsulated in a JWE (compact serialisation). Below is an overview of its structure:
ComponentDescription
JWE HeaderContains metadata such as the encryption algorithm (alg) and key identifier (kid).
Encrypted PayloadContains the Base64-encoded representation of the JWS (decrypted).
JWS HeaderIncludes metadata such as the signing algorithm (alg) and the key identifier (kid).
JWS PayloadContains claims, including user and authorization information.
SignatureEnsures the integrity and authenticity of the payload.
{% hint style="warning" %} Clients **must** use the kid field in the JWE header to identify the key Corppass used for encryption. Refer to [RFC 7515 Section 4](https://tools.ietf.org/html/rfc7515#section-4) for more information about the JWE structure. {% endhint %} #### **JWS Payload Example** The following an example of the JWS payload returned by the ID Token 
{
    "iat": 1623162109,
    "iss": "https://stg-id.corppass.gov.sg",
    "at_hash": "6J4VlBBQpbAyy1NL4NBW-Q",
    "sub": "s=S1234567P,uuid=0f14a2fc-09c2-4780-95f0-8c28347f2780,u=CP192,c=SG",
    "exp": 1623165709,
    "aud": "vOIljWVrGyBMK6f31QYq",
    "amr": ["pwd", "sms"],
    "nonce": "ZEF+97zc3YZP7huv6nzKspfabDv0wRtce/aVNud23vU=",
    "userInfo":{
        "CPAccType": "User",
        "CPUID_FullName": "John Grisham",
        "ISSPHOLDER": "YES"
    },
    "entityInfo": {
        "CPEntID": "82532759L",
        "CPEnt_TYPE": "UEN",
        "CPEnt_Status": "Registered",
        "CPNonUEN_Country": "",
        "CPNonUEN_RegNo": "",
        "CPNonUEN_Name": ""
    }
}
#### **Claims in the JWS Payload**
ClaimTypeDescription
audStringThe client ID of the Relying Party. Refer to Section 4.1.3 of RFC 7519.
issStringThe issuer of the token. Refer to Section 4.1.1 of RFC 7519.
iatNumberThe time the token was issued, expressed as a UNIX timestamp. Refer to Section 4.1.6 of RFC 7519.
expNumberThe expiration time of the token, expressed as a UNIX timestamp. The default validity is 10 minutes from iat. Refer to Section 4.1.6 of RFC 7519.
nonceStringA unique string to associate the ID Token with the authorization request to prevent replay attacks.
amrArrayAuthentication methods used during Singpass login
at_hashStringA hash of the Access Token issued alongside the ID Token.
subString

The principal that is the subject of the JWT. It contains a comma-separated list of key=value pairs that uniquely identify the user, which may include multiple alternate identifiers.

Format

The format of the sub is as follows:

  • s : Identity ID (e.g. NRIC/FIN/Foreign ID)
  • uuid : User's globally unique identifier (e.g. 0f14a2fc-09c2-4780-95f0-8c28347f2780 )
  • u : System-defined ID (e.g. CP1234 )
  • c : Two-character country code, conforming to ISO 3166-1 Alpha-2 (e.g. SG )

Example:

userInfoJSON

Contains the user's personal information, such as full name and account type.

Refer to the UserInfo Claim Structure section for more details.

entityInfoJSON

Includes the user's entity information (e.g., entity type, ID) used during authentication.

Refer to the EntityInfo Claim Structure section for more details.

# UserInfo Claim Structure The table below provides descriptions of the attributes included in the `UserInfo` claim of the ID Token. The value of the `UserInfo` claim is a JSON object, and it is a **mandatory** attribute in all Corppass ID Tokens. {% hint style="info" %} **Mandatory Attributes**: These attributes will always be present in the `UserInfo` object and will always contain a value, which could be a blank string if no data is available. **Non-Mandatory Attributes**: These attributes will only be included in the `UserInfo` object if data is available and they are not required by the schema. {% endhint %} The table below provides a detailed description of each attribute in the `UserInfo` claim of the ID Token.
FieldDescriptionData TypeLengthMandatory
CPAccTypeCorppass account type of the user. Indicates if the user is a Corppass Administrator, Sub-Administrator, User, or Enquiry User.String30Yes
CPUID_FullNameFull name of the authenticated user.String100Yes
ISSPHOLDERIndicates whether the user is a Singpass holder (i.e., has activated their Corppass ID using SingPass). Possible values are YES or NO.String3Yes
# EntityInfo Claim Structure The table below provides a detailed description of each attribute in the `EntityInfo` object, which is a mandatory claim in all Corppass ID Tokens. {% hint style="info" %} **Mandatory Attributes**: These attributes will always be present in the `EntityInfo` object and will always contain a value, which could be a blank string if no data is available. **Non-Mandatory Attributes**: These attributes will only appear if data is available and are not strictly required by the schema. {% endhint %}
FieldDescriptionData TypeLengthMandatory
CPEntIDUnique identifier for the entity, such as UEN (Unique Entity Number).String10Yes
CPEnt_Status

Status of the entity in Corppass as provided by issuance agencies. The possible values for entity status are:

  • Registered
  • De-Registered
  • Withdrawn
  • Blank (Specific for Non-UEN scenario)
String20Yes
CPEnt_TYPE

Type of Entity that the user belongs to. The possible values for entity type are:

  • UEN
  • NON-UEN (Includes non-UEN entities as well as ASGD/ITR entities)
  • GSTN
String10Yes
CPNonUEN_RegNoEntity registration number of Non-UEN entity which is entered during Corppass Admin registration. Value will be "" if user belongs to UEN entity.String15Yes
CPNonUEN_CountryCountry of incorporation of Non-UEN entity which is provided during Corppass Admin registration. Value will be "" if user belongs to UEN entity.String2Yes
CPNonUEN_NameName of Non-UEN entity which is entered during Corppass Admin registration. Value will be "" if user belongs to UEN entity.String100Yes
# Access Token Structure The Access Token is a signed JWS consumed by Corppass resource servers. {% hint style="warning" %} Relying Parties (RPs) **must treat the Access Token as opaque** and **must not** attempt to parse or interpret its content. {% endhint %} JWT Payload Example: ```json { "iat": 1716451740, "exp": 1716452339, "iss": "https://stg-id.corppass.gov.sg", "scope": "authinfo tpauthinfo", "aud": ["https://stg-id.corppass.gov.sg/authorization-info"], "client_id": "97ZZnLxUfzzVz50kfCwB",  "sub": "s=S1234567P,uuid=0f14a2fc-09c2-4780-95f0-8c28347f2780,u=CP192,c=SG", "jti": "vhC0eLzU-ol8IQ0RuFL5f" } ``` The JWS payload includes the following claims:
ClaimTypeDescription
audArrayThe URI of the resource server(s) for which the Access Token is intended. Refer to Section 4.1.3 of RFC 7519.
issStringThe issuer of the Access Token. Refer to Section 4.1.1 of RFC 7519.
iatNumberThe time at which the Access Token was issued, expressed as a UNIX timestamp. Refer to Section 4.1.6 of RFC 7519.
expNumberThe expiration time on or after which the Access Token MUST NOT be accepted for processing. Defaults to 10 minutes since iat. Refer to Section 4.1.4 of RFC 7519.
scopeStringA space-separated list of scopes granted by the token, which defines the permissions for the resource server.
subStringThe principal that is the subject of the JWT. It contains a comma-separated list of key=value pairs that uniquely identify the user, which may include multiple alternate identifiers.
client_idStringThe client ID of the Relying Party for which the Access Token is intended.
jtiStringThe unique identifier of the token.
# Authorization Info Endpoint ``` POST /authorization-info  ``` The Authorization Info Endpoint allows the Relying Party (RP) to retrieve detailed authorization information about the authenticated user. To access this enpdoint, the RP must include a valid Access Token issued by the `/token` endpoint in the `Authorization` header as a Bearer token. {% hint style="danger" %} In the previous minor version (2.0), the practice of appending the `scope` in the request body was supported. This behavior has been removed in the current version. The `scope` parameter should now be assessed at the **Authorize Endpoint** rather than the **Authorization Info Endpoint**. Therefore, appending `scope` in the request body is no longer supported. While this change will not impact RPs (Relying Parties) who are still appending `scope` in the request body, we strongly encourage RPs to deprecate this implementation to simplify the network calls and ensure compatibility with the updated version. {% endhint %} #### Request Headers
FieldRequiredDescription
AuthorizationYes

The Access Token issued by the /token endpoint, passed as a Bearer token in the header.

Example:

Authorization: Bearer <Access-Token>

#### Response The Authorization Info Endpoint returns authorization claims encapsulated in a JWS. The payload contains information about the user's roles, entities, and third-party authorizations. Response Body Example {% code overflow="wrap" %} ```json { "iat": 1624086842, "exp": 1624087442, "aud": "vOIljWVrGyBMK6f31QYq", "iss": "https://stg-id.corppass.gov.sg", "sub": "vOIljWVrGyBMK6f31QYq", "AuthInfo": { "Result_Set": { "ESrvc_Row_Count": 1, "ESrvc_Result": [ { "CPESrvcID": "SD-CPF2FA", "Auth_Result_Set": { "Row_Count": 1, "Row": [ { "CPEntID_SUB": "", "CPRole": "CPF2FAR1", "StartDate": "2020-08-28", "EndDate": "9999-12-31", "Parameter": [ { "name": "Free Text", "value": "" }, ] } ] } } ] } }, "TPAuthInfo": { "Result_Set": { "ESrvc_Row_Count": 1, "ESrvc_Result": [ { "CPESrvcID": "AGM02", "Auth_Set": { "ENT_ROW_COUNT": 1, "TP_Auth": [ { "CP_Clnt_ID": "VBR000036", "CP_ClntEnt_TYPE": "UEN", "Auth_Result_Set": { "Row_Count": 1, "Row": [ { "CP_ClntEnt_SUB": "", "CPRole": "", "StartDate": "2020-07-29", "EndDate": "9999-12-31", "Parameter": [] } ] } } ] } } ] } } } ``` {% endcode %} Response Claims
ClaimTypeDescription
audStringThe client ID of the Relying Party (RP). Refer to Section 4.1.3 of RFC 7519.
issStringThe issuer of the JWT. Refer to Section 4.1.1 of RFC 7519.
subStringThe unique user identifier (e.g. client ID) for the authenticated user.
iatNumberThe time the JWT was issued, expressed as a UNIX timestamp. Refer to Section 4.1.6 of RFC 7519.
expNumberThe expiration time of the JWT. Defaults to 10 minutes from iat. Refer to Section 4.1.4 of RFC 7519.
AuthInfoJSONAuthorization information assigned to the user.
TPAuthInfoJSONThird-party authorization information assigned to the user.
# AuthInfo Structure The `AuthInfo` claim provides detailed user authorization information. The table below describes the fields included in the `AuthInfo` claim returned by the [Authorization Info Endpoint](/technical-specifications/corppass-authorization-api-legacy/endpoints/authorization-info-endpoint#response). {% hint style="info" %} **Mandatory Field**: Always present in the object and contain values, which could be a blank string if no data is available. **Non-Mandatory Field**: Included only if data is available and not required by the schema. {% endhint %}
FieldDescriptionData TypeLengthMandatory
Auth_Result_SetJSON object contains authorization result for the user for a specific Digital Service.JSON-Yes
CPEntID_SUBSub-UEN value of that entity to which the user is assigned the authorization. Sub-UEN is a mandatory attribute for a Digital Service if there is no value was supplied, "ERROR_MISSING_VALUE" will be returned for the field.String32Yes
CPESrvcIDID of the Digital Service that is requesting the authorization.String25Yes
CPRoleThe role assigned to the user for that Digital Service.String20Yes
EndDateThe end date for validity of the role i.e. the date at which this role is no longer valid for the user for that Digital Service.String (format YYYY-MM-DD)10Yes
ESrvc_ResultArray of JSON objects, each object contains authorization details for a specific Digital Service.
There could be scenario where ESrvc_Row_Count = 0, when ESrvc_Row_Count = 0, ESrvc_Result will be an empty array		Array of JSON-Yes
ESrvc_Row_CountThis value indicates the number of Digital Services for which the authorizations are present in the Result_Set JSON object.Integer10Yes
nameParameter name defined by defined by Digital Service administratorString30No
ParameterThis is optional array of parameters (JSON objects containing only name and value pair attributes) defined by Digital Service administrator. These parameters will be populated as required. These parameters use a name-value pair format and will contain the "Digital Service defined name" from Corppass in the name field.
If no parameters are defined this will be returned as empty array.
If a parameter is defined as mandatory by the Digital Service administrator but no value was supplied, "ERROR_MISSING_VALUE" will be returned for the field.		Array of JSON-Yes
Result_SetDigital Service authorization result set.JSON-Yes
RowArray of JSON objects, each JSON object represents actual authorization values for a given Sub-UEN for a user.Array of JSON-Yes
Row_CountThe count of the number of rows included in the auth result set e.g. If the user access to two Sub-UENs within the same entity, the result set will contain two rows with the role information for each Sub-UEN in one individual row.Integer10Yes
StartDateThe start date for validity of the role i.e. the date from which this role is valid for the user for that Digital Service.String (format YYYY-MM-DD)10Yes
valueParameter value defined by defined by Digital Service administratorString66No
# TPAuthInfo Structure The `TPAuthInfo` claim provides details about third-party authorizations for the user. This claim is included in the [Authorization Info Endpoint](/technical-specifications/corppass-authorization-api-legacy/endpoints/authorization-info-endpoint#response) response only for scenarios where the user is associated with the third-party functionality within a Digital Service. ### **Third-Party Authorization Scenarios** For Digital Services that support third-party functionality, if a third-party user logs in using Corppass, an additional `TPAuthInfo` object will be shared alongside the `AuthInfo` object. A user may have multiple authorizations for a given Digital Service as a third party. * **Example**: For a GST Digital Service, a third-party entity may have 5 clients. If the user is authorized to file GST for all 5 clients, the ser will have 5 third-party authorizations. ### **Attributes in `TPAuthInfo` Claim** The table below provides a detailed description of the attributes included in the `TPAuthInfo` claim. The `TPAuthInfo` object is optional and only present for third-party scenarios.
FieldDescriptionData TypeLengthMandatory
Auth_Result_SetJSON object contains authorization assigned for that client entity for the userJSON-Yes
Auth_SetJSON object contains authorization result for the user for a specific Digital Service.JSON-Yes
CP_Clnt_IDContains the client entity IDString10Yes
CP_ClntEnt_SUBSub-UEN value of that entity to which the user is assigned the authorization. Sub-UEN is an optional attribute for a Digital Service and therefore can be blank.String32Yes
CP_ClntEnt_TYPE

Contains the client entity type. The possible values for entity type are:

  • UEN
  • NON-UEN (Includes non-UEN entities as well as ASGD/ITR entities)
  • GSTN
String10Yes
CPESrvcIDID of the Digital Service that is requesting the authorization.String25Yes
CPRoleThe role assigned to the user for that particular Sub-UENString20Yes
EndDateThe end date for validity of the role i.e. the date at which this role is no longer valid for the user for that Digital ServiceString (format YYYY-MM-DD)10Yes
ENT_ROW_COUNTIndicates the number of rows in the third-party assignment. This is equal to the number of clients that the user is authorized as third party for that Digital ServiceInteger10Yes
ESrvc_ResultJSON object contains authorization details for a specific Digital Service.JSON-Yes
ESrvc_Row_CountThis value indicates the number of Digital Services for which the authorizations are present in the Result_Set JSON object. This value will be set to 1.Integer10Yes
nameParameter name defined by defined by Digital Service administratorString30No
ParameterThis is optional array of parameters (JSON objects containing only name and value pair attributes) defined by Digital Service administrator. These parameters will be populated as required. These parameters use a name-value pair format and will contain the "Digital Service defined name" from Corppass in the name field.
If no parameters are defined this will be returned as empty array.
If a parameter is defined as mandatory by the Digital Service administrator but no value was supplied, "ERROR_MISSING_VALUE" will be returned for the field.		Array of JSON-Yes
Result_SetDigital Service authorization result set.JSON-Yes
RowArray of JSON objects, each JSON object represents actual authorization values for a given sub-UEN for a user.Array of JSON-Yes
Row_CountThe count of the number of rows included in the result set e.g. If the user access to two sub-UENs within the same entity, the result set will contain two rows with the role information for each sub-UEN in one individual row.Integer10Yes
StartDateThe start date for validity of the role i.e. the date from which this role is valid for the user for that Digital ServiceString (format YYYY-MM-DD)10Yes
TP_AuthArray of JSON objects, each JSON object represents authorization of the user for one client only.Array of JSON-Yes
valueParameter value defined by defined by Digital Service administratorString66No
# Well-known Endpoints Corppass provides well-known endpoints that facilitate secure authentication and authorization processes. These endpoints are publicly accessible and serve essential metadata and cryptographic keys for client applications. Refer to the respective sections for detailed specifications and implementation guidelines: {% content-ref url="/pages/wcyo5BRxEn1vxsCrOtQ4" %} [OpenID Discovery Endpoint](/technical-specifications/corppass-authorization-api-legacy/endpoints/well-known-endpoints/openid-discovery-endpoint) {% endcontent-ref %} {% content-ref url="/pages/pItpg8bX5p156OJpZ8oJ" %} [JWKS Endpoint](/technical-specifications/corppass-authorization-api-legacy/endpoints/well-known-endpoints/jwks-endpoint) {% endcontent-ref %} # OpenID Discovery Endpoint ``` GET /.well-known/openid-configuration ``` The OpenID Discovery Endpoint provides essential metadata about the OpenID Provider (OP) configuration. This metadata allows Relying Parties (RPs) to dynamically configure their interactions with the OP. {% hint style="info" %} Responses from the OpenID Discovery Endpoint should be cached for at least 1 hour to minimize repeated requests during OIDC/OAuth2 operations. {% endhint %} #### Response Response Example ```http HTTP/2 200 content-type: application/json; charset=utf-8 content-length: 1667   { "authorization_endpoint": "https://stg-id.corppass.gov.sg/mga/sps/oauth/oauth20/authorize", "claims_parameter_supported": false, "claims_supported": [ "nonce", "aud", "iss", "sub", "exp", "iat", "userInfo", "entityInfo", "AuthInfo", "TPAuthInfo", "rt_hash", "at_hash", "amr", "email", "email_verified", "sid", "auth_time", "EntityInfo" ], "code_challenge_methods_supported": [ "S256" ], "grant_types_supported": [ "authorization_code" ], "issuer": "https://stg-id.corppass.gov.sg", "jwks_uri": "https://stg-id.corppass.gov.sg/.well-known/keys", "authorization_response_iss_parameter_supported": true, "response_modes_supported": [ "form_post", "fragment", "query" ], "response_types_supported": [ "code" ], "scopes_supported": [ "openid" ], "subject_types_supported": [ "public" ], "token_endpoint_auth_methods_supported": [ "private_key_jwt" ], "token_endpoint_auth_signing_alg_values_supported": [ "ES256", "ES256K", "ES384", "ES512" ], "token_endpoint": "https://stg-id.corppass.gov.sg/mga/sps/oauth/oauth20/token", "id_token_signing_alg_values_supported": [ "ES256" ], "id_token_encryption_alg_values_supported": [ "ECDH-ES+A128KW", "ECDH-ES+A192KW", "ECDH-ES+A256KW" ], "id_token_encryption_enc_values_supported": [ "A256CBC-HS512" ], "request_parameter_supported": false, "request_uri_parameter_supported": false, "userinfo_endpoint": "https://stg-id.corppass.gov.sg/authorization-info", "userinfo_signing_alg_values_supported": [ "ES256" ], "userinfo_encryption_alg_values_supported": [ "A128KW", "A256KW", "ECDH-ES", "RSA-OAEP", "RSA-OAEP-256", "dir" ], "userinfo_encryption_enc_values_supported": [ "A128CBC-HS256", "A128GCM", "A256CBC-HS512", "A256GCM" ], "claim_types_supported": [ "normal" ], "name": "corppass", "authorization-info_endpoint": "https://stg-id.corppass.gov.sg/authorization-info" } ``` Response Fields
FieldTypeDescription
issuerStringThe URL identifying the OpenID Provider (OP) as the issuer of tokens. Defined in RFC 7519, Section 4.1.1.
authorization_endpointStringThe URL of the OP's OAuth 2.0 Authorization Endpoint, where users authenticate and provide consent. Refer to OpenID Connect Core 1.0, Section 3.1.2.
jwks_uriStringThe URL of the OP's JSON Web Key Set (JWKS) endpoint. Clients use this endpoint to retrieve public keys for validating token signatures. Refer to RFC 7517, Section 4.
response_types_supportedArrayJSON array containing a list of OAuth 2.0 response_type values that the OP supports. Defined in OAuth 2.0 Multiple Response Type Encoding Practices.
scopes_supportedArrayJSON array listing the OAuth 2.0 scope values that the OP supports, such as openid, which is mandatory for OpenID Connect flows.
subject_types_supportedArrayJSON array containing a list of Subject Identifier types that the OP supports, such as public or pairwise. Refer to OpenID Connect Core 1.0, Section 8.
claims_supportedArrayJSON array containing a list of Claim Names the OP may supply in tokens or the UserInfo response. Defined in OpenID Connect Core 1.0, Section 5.1.
grant_types_supportedArrayJSON array listing the OAuth 2.0 grant_type values supported by the OP, such as authorization_code or refresh_token. Refer to RFC 6749, Section 4.
token_endpointStringThe URL of the OP's OAuth 2.0 Token Endpoint. Clients exchange an authorization code for tokens at this endpoint.
token_endpoint_auth_methods_supportedArrayJSON array listing the client authentication methods supported by the Token Endpoint, such as private_key_jwt. Refer to OpenID Connect Core 1.0, Section 9.
token_endpoint_auth_signing_alg_values_supportedArrayJSON array listing the JWS signing algorithms (alg values) supported by the Token Endpoint for JWT authentication. Refer to RFC 7518, Section 3.1.
id_token_signing_alg_values_supportedArrayJSON array listing the JWS signing algorithms (alg values) supported by the OP for signing ID Tokens. Defined in RFC 7518, Section 3.1.
id_token_encryption_alg_values_supportedArrayJSON array listing the JWE encryption algorithms (alg values) supported by the OP for encrypting ID Tokens. Defined in RFC 7516, Section 4.1.1.
id_token_encryption_enc_values_supportedArrayJSON array listing the JWE encryption algorithms (enc values) supported by the OP for encrypting ID Tokens. Defined in RFC 7516, Section 4.1.2.
authorization-info_endpointStringThe URL of the OP's Authorization Info Endpoint, used to retrieve the user's authorization and third-party authorization details.
claims_parameter_supportedBooleanBoolean value indicating whether the OP supports the claims parameter to request specific claims. If omitted, the default value is false. Refer to OpenID Connect Core 1.0, Section 5.5.
code_challenge_methods_supportedArrayJSON array listing the Proof Key for Code Exchange (PKCE) code_challenge methods supported by the OP, such as S256. Defined in RFC 7636, Section 4.3.
authorization_response_iss_parameter_supportedBooleanBoolean indicating whether the OP includes the iss parameter in the authorization response. This is set to true.
response_modes_supportedArrayJSON array listing OAuth 2.0 response_mode values supported by the OP, such as query or fragment. Defined in OAuth 2.0 Multiple Response Type Encoding Practices.
request_parameter_supportedBooleanBoolean indicating whether the OP supports the request parameter for JWT-based requests. Default is false if omitted.
request_uri_parameter_supportedBooleanBoolean indicating whether the OP supports the request_uri parameter. Default is true if omitted.
claim_types_supportedArrayJSON array listing the Claim Types supported by the OP, such as normal, aggregated, or distributed. Defined in OpenID Connect Core 1.0, Section 5.6.
userinfo_endpointStringThe URL of the OP's UserInfo Endpoint, used to retrieve claims about the authenticated user. Defined in OpenID Connect Core 1.0, Section 5.3.
userinfo_signing_alg_values_supportedArrayJSON array listing JWS signing algorithms (alg values) supported by the UserInfo Endpoint for encoding claims in a JWT. Defined in RFC 7515, Section 4.
userinfo_encryption_alg_values_supportedArrayJSON array listing JWE encryption algorithms (alg values) supported by the UserInfo Endpoint for encrypting claims in a JWT. Defined in RFC 7516, Section 4.1.1.
userinfo_encryption_enc_values_supportedArrayJSON array listing JWE encryption algorithms (enc values) supported by the UserInfo Endpoint for encrypting claims in a JWT. Defined in RFC 7516, Section 4.1.2.
{% hint style="info" %} The `userinfo_endpoint` in OIDC is analogous to the `authorization-info_endpoint` in the Corppass Authorization system, which provides similar functionalities, offering detailed information about the authenticated user after a successful login. {% endhint %} # JWKS Endpoint ``` GET /.well-known/keys ``` Corppass signs all JSON Web Tokens (JWTs) issued during the authentication and authorization process using a dedicated signing key. RPs can validate these JWT signatures by retrieving the signing public key from the Corppass JSON Web Key Set (JWKS) endpoint. This endpoint returns one or more public keys in JSON Web Key (JWK) format. To validate a JWT signature: 1. Use the JWK where the `use` attribute is set to `sig` (indicating a signing key). 2. Ensure the `kid` value in the JWK matches the `kid` value in the JWT’s JOSE header. {% hint style="info" %} Responses from this endpoint, or individual keys within the JWKS, should be cached for at least 1 hour to avoid retrieving the JWKS for every JWT validation {% endhint %} #### Response Response Example ```http HTTP/2 200 content-type: application/jwk-set+json; charset=utf-8 content-length: 955 { "keys": [ { "kty": "EC", "use": "sig", "kid": "OvNklZwNmhiE6tu9mtWTDAv218k2DMjuRaGhkBgFdOo", "alg": "ES256", "crv": "P-256", "x": "gnbm-h8k3ZzeegHK0x87wO_SP_MLFts9XPZm7pE8U04", "x5c": [ "MIIB2TCCAYCgAwIBAgIUWSJjkrsmm08OFT3PDSegP/6fTXwwCgYIKoZIzj0EAwIwRDELMAkGA1UECAwCU0cxCzAJBgNVBAcMAlNHMQswCQYDVQQKDAJDUDEMMAoGA1UEAwwDTkRJMQ0wCwYDVQQLDARTUENQMB4XDTI0MTExMTA1MjYyMloXDTI2MTExMDA1MjYyMlowRDELMAkGA1UECAwCU0cxCzAJBgNVBAcMAlNHMQswCQYDVQQKDAJDUDEMMAoGA1UEAwwDTkRJMQ0wCwYDVQQLDARTUENQMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEgnbm+h8k3ZzeegHK0x87wO/SP/MLFts9XPZm7pE8U04m+1m09SoBLrzftqyIia3H6g7TnBBL5nqU6d6r3OL+pKNQME4wHQYDVR0OBBYEFBShdiaEMMNlMU15ewIkmCdBQFZOMB8GA1UdIwQYMBaAFBShdiaEMMNlMU15ewIkmCdBQFZOMAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwIDRwAwRAIgIrv7vCRg/XGmPz74X3Ygs5gV2jEPCvPCBtyU/hR59GYCIGPBWS1/DmvQztjoknyjv8fvop7QUiTf8jotrZc4ssDK" ], "y": "JvtZtPUqAS6837asiImtx-oO05wQS-Z6lOneq9zi_qQ", "x5t": "ljFP32-_2i4WJZ0vo0UM-8Xr5oI", "x5t#S256": "OvNklZwNmhiE6tu9mtWTDAv218k2DMjuRaGhkBgFdOo" } ] } ``` **JWKS Key Rotation** Corppass reserves the right to rotate or update its signing keys at any time and without prior notice. When a key rotation occurs: 1. New keys will be published to the JWKS endpoint and will include a unique `kid` value. 2. JWTs issued after the rotation will reference the updated `kid` in their JOSE headers. 3. RPs **must** refresh their cached JWKS by querying the JWKS endpoint to retrieve the updated keys. It is essential for RPs to implement proper handling for key rotations to ensure uninterrupted validation of JWT signatures. {% hint style="danger" %} The following fields will be **deprecated** in the next major version of the API: * x5c * x5t * x5t#S256 Plan to update your applications to remove reliance on these fields. We strongly recommend reviewing the updated API documentation and transitioning to alternative fields as soon as possible to avoid disruptions. {% endhint %} # Scopes Scopes define the permissions and claims the client requests from the authorization server during the OIDC flow. The `scope` parameter is mandatory in the authorization request and must include `openid`. Additional scopes may be requested to obtain specific claims or access certain resources. {% hint style="warning" %} The scope parameter will be **mandated** in the next major version of the API. Once the scope parameter is mandated, any requested scope that is **not recognized or authorized** by the authorization server will **result in an error**.\ \ Plan to update your applications to include this parameter. We strongly recommend reviewing the updated API documentation and transitioning to alternative fields as soon as possible to avoid disruptions. {% endhint %} #### **Supported Scopes**
ScopeDescriptionData Access
openid

Mandatory scope to indicate the request is an OpenID Connect flow.

Required for all requests.

authinfoView authorization details for the authenticated user.

Auth Info Endpoint

  • AuthInfo
tpauthinfoView third-party authorization details for the authenticated user.

Auth Info Endpoint

  • TPAuthInfo
**Usage Example** When requesting scopes in the authorization URL, include them as a space-separated list in the `scope` parameter: **Example Request** ```http https://stg-id.corppass.gov.sg/mga/sps/oauth/oauth20/authorize ?client_id=example_client &response_type=code &scope=openid authinfo &redirect_uri=https://example.com/callback &state=xyz123 &nonce=abc456 ``` # Changelog ### **v2.3 (8-Feb-2025)** #### **New Features** * **Pushed Authorization Request (PAR) Flow Support** * Added a new section detailing the **Pushed Authorization Request (PAR) Endpoint**. * This allows clients to push authorization requests **directly to the server** before redirecting users for authentication. * **Client Authentication with Client Assertion JWT** * Introduced a dedicated section explaining JWT-based client authentication. * Added `jti` (JWT ID) claim, which will be **mandatory** in a future major release. #### **Deprecations** * **`esrvcID` Query Parameter (Authorization Endpoint)** * Marked for deprecation. Clients should **avoid relying on `esrvcID`** as it will be removed in an upcoming release. *** ### **v2.2 (15-Jan-2025)** #### **Deprecations** * **Authorization Endpoint: `esrvcID` Query Parameter** * Added an official **deprecation notice** for `esrvcID`. RPs should transition away from this parameter. *** ### **v2.1 (26-Nov-2024)** #### **Major Updates** * **Introduction & Documentation Improvements** * Clarified the **OIDC flow diagram** with a **focused summary**. * Improved readability in key sections. * **OpenID Discovery Endpoint** * **Added support for new algorithms**: * Signing: `ES256K`, `ES384`, `ES512` * Encryption: `ECDH-ES+A128KW`, `ECDH-ES+192KW` * **Added user claims:** `email`, `email_verified` * **Authorization Endpoint** * Introduced a **"Required"** column in the request parameters table for clarity. * **Changed HTTP redirect behavior:** * Redirects during Singpass login now return **HTTP 303 (See Other)** instead of **302 (Found)**. * Removed outdated **curl request examples**. * **Token Endpoint** * **Client Assertion JWT Updates** * Introduced the `jti` (JWT ID) claim for **client authentication**. * This will become **mandatory in the next major version**. * **Access Token Structure Changes** * Updated descriptions for `scope` and `sub`. * **Added `client_id` and `jti` claims** to the access token. * **Removed curl request examples** for better maintainability. * **ID Token Structure** * Clarified that the **order of key-value pairs in `sub` is not guaranteed**. * Added support for `email` and `email_verified` claims. * **Authorization Info Endpoint** * **Changed HTTP method from `POST` to `GET`**. * **Deprecated** the use of `scope` in request bodies. * **New Sections Added** * **Overview of JWS & JWE** * **Scopes Overview** *** ### **v2.0 (16-May-2024)** #### **Breaking Changes** * **Authorization Endpoint Redirect Code Change** * Redirect behavior during Singpass login changed from **HTTP 302** to **HTTP 303** to align with best practices. * **Authorization Info Endpoint** * **New Claims Introduced**: `sub` now included. * **Error Handling Enhancements**: Added standardized error responses. * **Token Endpoint** * **Error Fields Section Added** to provide more detailed error messages. * **Single Sign-On (SSO) Discontinued** * Officially **removed SSO support**. RPs should transition to alternative authentication methods. *** ### **v1.5 (11-Apr-2024)** #### **Fixes** * **Hyperlink Fixes in Staging & Production URLs** *** ### **v1.4 (1-Jun-2023)** #### **Fixes** * **Face Verification AMR Claim Update** * Corrected the return value for **Face Verification (`AMR` claim)** from `"fb"` to `"fv"`. *** ### **v1.3 and Older** * Minor documentation updates and schema refinements. * Inclusion of `uuid` in `sub` claim (v1.2). # Technical Concepts This section provides foundational knowledge required to successfully integrate with the **Corppass Authorization API**. It introduces the core standards, security mechanisms, and token structures that underpin Corppass’s authentication and authorization flows. Understanding these concepts is critical for implementing secure, standards-compliant interactions between **Relying Parties (RPs)** and **Corppass**, and ensures alignment with the **OpenID Connect (OIDC)** and **OAuth 2.0** protocols. ### What This Section Covers * [**Client JWKS** ](/technical-specifications/technical-concepts/client-jwks)– How public keys are published and rotated for signature/encryption validation. * [**JWS and JWE**](/technical-specifications/technical-concepts/jws-and-jwe) – Token formats used to sign or encrypt authentication data. * [**Client Assertion JWT**](/technical-specifications/technical-concepts/client-assertion-jwt) – A secure, private-key-based method for client authentication. * [**Proof Key for Code Exchange (PKCE)** ](/technical-specifications/technical-concepts/proof-key-of-code-exchange-pkce)– Mitigates code interception during OAuth flows. * [**Demonstrating Proof of Possession (DPoP)**](/technical-specifications/technical-concepts/demonstrating-proof-of-possession-dpop) – Ensures tokens and auth codes are bound to a client-held key and can't be replayed. ### Standards and Specifications Reference For developers who are interested in the underlying standards Corppass adheres to
ReferenceSummary
OpenID Connect Core 1.0Defines the core protocol for identity authentication built on top of OAuth 2.0. Covers ID tokens, user authentication flows, and UserInfo endpoints.
OpenID Connect OverviewHigh-level overview of OpenID Connect and its role in identity federation and SSO. Ideal starting point for newcomers.
RFC 7519: JSON Web Token (JWT)Defines the structure of JWTs — compact, URL-safe tokens used for conveying claims securely between parties.
RFC 7515: JSON Web Signature (JWS)Describes how to digitally sign content (like JWTs) to ensure integrity and authenticity. Used in ID/access tokens.
RFC 7516: JSON Web Encryption (JWE)Describes how to encrypt content (like ID tokens) to protect confidentiality. Used when issuing encrypted ID tokens.
RFC 7636: PKCE (Proof Key for Code Exchange)An extension to OAuth 2.0 that adds security to public clients by mitigating code interception attacks.
RFC 7523: JWT Profile for OAuth 2.0 Client AuthenticationSpecifies how clients can use signed JWTs to authenticate to the token endpoint — used in Client Assertion JWT.
RFC 8705: OAuth 2.0 DPoPDefines a proof-of-possession mechanism for OAuth 2.0 to bind access tokens to a public key. Used to prevent token replay and enforce sender-constrained access. RPs must generate and sign a DPoP proof JWT with every protected API request.
FAPI 2.0 Security ProfileSpecifies a high-security profile for OpenID and OAuth APIs. Includes requirements for DPoP, JWS-request objects, client authentication, and error handling best practices.
JSON Schema Draft 07Defines how JSON structures are validated — used to describe token claims, payloads, or configuration metadata.
# Client JWKS Clients must provide public keys in the JSON Web Key (JWK) format to enable secure signing and encryption operations. These keys are essential for verifying signed client requests and for encrypting ID tokens returned by Corppass. Clients authenticating with Corppass using **JWT-based client assertions** must expose a **JSON Web Key Set (JWKS)** at a publicly accessible URL. This allows Corppass to verify the digital signatures of JWTs submitted with PAR (Pushed Authentication Request) or token requests. ## What is a JWKS? A JWKS is a JSON document that contains one or more **public keys**. Each key corresponds to a private key that the client uses to sign JWTs. Corppass uses the `kid` (Key ID) in the JWT header to find the matching key in the JWKS and verify the signature. {% hint style="warning" %} Ensure that the private key component (`d`) is **never** **included** in the JWK. Only public key parameters such as `x`, `y`, `e`, `n` should be exposed to maintain the security of cryptographic operations. {% endhint %} ### Hosting your JWKS Clients integrating with Corppass **must adhere** to the following service-level requirements to ensure secure and reliable interactions: * **HTTPS Requirement**: The JWKS endpoint must be served over **HTTPS on port 443**, using a **publicly trusted and verifiable TLS certificate**. * **Performance**: The endpoint should respond within **3 seconds** to ensure optimal performance and minimal authentication latency. * **Key Availability**: The JWKS must always include at least one valid public key for signing and encryption respectively. * **Direct Accessibility:** The configured JWKS endpoint URL must return the JWKS response directly and should not perform HTTP redirects (e.g. 301, 302, 307). ### JWKS Example 
{
  "keys": [
    { 
      "kty": "EC", 
      "use": "sig",
      "alg": "ES256",
      "kid": "UErQ3h_cFg3FQHrWFwAj7RPyeHjPoO7mj3IWj2jGhso", 
      "x": "7eArnDiZnGA0Pg115rH4X0VHbnI00fVag1wbLihruF4", 
      "y": "eK6jKnD1P4f9hsjZ9v4W6ZTuhwd87R01ClK1NEYAdoI", 
      "crv": "P-256" 
    },
    {
      "kty": "EC", 
      "use": "enc",
      "alg": "ECDH-ES+A128KW",
      "kid": "SfyArsBpqSONSMkYid3snFYPea69t1Blc-tiDaUUlVs", 
      "x": "xom6kD54yfXRPvMFVYFlVjUKzmNhz7wf0DP_2h9kXtY", 
      "y": "lrh8C9c8-SBJTm1FcfqLkj2AnHtaxpnB1qsN6PiFFJE",
      "crv": "P-256"
    }
  ]
}
### JWK for Signing The signing JWK is used to verify the **Client Assertion JWT** submitted during token requests. #### An example of Signing JWK (ES256, P-256 Curve): 
{ 
  "kty": "EC", 
  "use": "sig", 
  "alg": "ES256", 
  "kid": "UErQ3h_cFg3FQHrWFwAj7RPyeHjPoO7mj3IWj2jGhso",
  "x": "7eArnDiZnGA0Pg115rH4X0VHbnI00fVag1wbLihruF4", 
  "y": "eK6jKnD1P4f9hsjZ9v4W6ZTuhwd87R01ClK1NEYAdoI", 
  "crv": "P-256" 
}
ClaimDescription
ktySpecifies the key type. Must be "EC" to denote an Elliptic Curve key.
useIndicates the intended use of the key. Must be set to sig to specify that the key is used for digital signature operations.
algDefines the algorithm intended for use with the key. Supported values are: ES256, ES256K, ES384, and ES512.
kidA unique identifier that helps Corppass select the correct key for verifying client assertions.
crv

Indicates the elliptic curve used. Supported values are:

  • P-256 (NIST secp256r1)
  • P-384 (NIST secp384r1)
  • P-521 (NIST secp521r1)
  • secp256k1
### JWK for Encryption The encryption JWK is used to encrypt sensitive responses returned by the Authorization Server, including the ID Token issued at the `/token` endpoint and the payload from the `/userinfo` resource endpoint. This ensures that only the intended recipient (the client) can decrypt and access the protected information. Clients must publish a valid public encryption key in JWK format to enable this secure transmission. #### An example of an Encryption JWK (ECDH-ES+A128KW, P-256 Curve) ```json { "kty": "EC", "use": "enc", "alg": "ECDH-ES+A128KW", "kid": "SfyArsBpqSONSMkYid3snFYPea69t1Blc-tiDaUUlVs", "x": "xom6kD54yfXRPvMFVYFlVjUKzmNhz7wf0DP_2h9kXtY", "y": "lrh8C9c8-SBJTm1FcfqLkj2AnHtaxpnB1qsN6PiFFJE", "crv": "P-256", } ```
ClaimDescription
ktySpecifies the key type. Must be "EC" to indicate an Elliptic Curve key.
useIndicates the intended use of the key. Must be set to "enc" to specify that the key is used for encryption.
algDefines the key management algorithm used for encryption. Supported values are: ECDH-ES+A128KW, ECDH-ES+A192KW, and ECDH-ES+A256KW.
kidA unique identifier that allows the Authorization Server to select the correct public key for encrypting responses.
crvIndicates the elliptic curve used. Supported values are: P-256 (NIST secp256r1), P-384 (NIST secp384r1), and P-521 (NIST secp521r1).
## Key Rotation Guidelines To maintain strong security hygiene and align with best practices, clients **should** rotate their signing and encryption keys regularly. Corppass supports seamless key rotation without downtime by allowing clients to publish multiple keys in their JWKS. The Authorization Server uses the `kid` (Key ID) value in incoming JWTs to select the appropriate key for verification or encryption. By following the steps below, clients can introduce new keys and deprecate old ones without impacting ongoing integrations. ### Signing Key Rotation
TimeAction
PrepThe Relying Party (RP) generates a new signing key pair (K2) for use in signing client assertions.
T0The RP publishes the new public key (K2) to its JWKS endpoint, while retaining the existing key (K1).
T0 - T+1 hourCorppass retrieves the RP’s updated JWKS, which now includes K2. It uses the kid value in the client assertion's header to identify the correct key for signature verification
> T+1 hourThe RP begins signing client assertions using the new key (K2).
Clean UpOnce confident that K2 is in use and functioning correctly, the RP may remove the old key (K1) from its JWKS endpoint.
### Encryption Key Rotation
TimeAction
PrepThe Relying Party (RP) generates a new encryption key pair (K2) for decrypting tokens. The existing key pair (K1) remains available for decrypting ID tokens.
T0The RP updates its JWKS endpoint by removing public key K1 and adding the new public key K2.
T0 - T+1 hourCorppass begins encrypting ID tokens and other protected payloads using the new encryption key (K2).
> T+1 hour

During key rotation, Corppass may begin encrypting ID tokens using a new key (K2), while some tokens may still be issued using the previous key (K1) due to caching or propagation delays.

Relying Parties (RPs) must implement dynamic decryption by inspecting the kid field in the JWE header to determine which decryption key (K1 or K2) to use.


Failure to support multiple active decryption keys during rotation may result in decryption failures or rejected tokens.

Clean UpOnce the RP confirms that no new tokens are being encrypted with K1, it can safely remove support for decrypting with K1.
# JWS and JWE Corppass leverages **JWS (JSON Web Signature)** and **JWE (JSON Web Encryption)** to securely exchange and verify sensitive authorization data between clients and the authorization server. These mechanisms align with [RFC 7515](https://www.rfc-editor.org/rfc/rfc7515.html) (JWS) and [RFC 7516](https://datatracker.ietf.org/doc/html/rfc7516) (JWE), and are used to ensure **integrity**, **authenticity**, and **confidentiality** of data in the Corppass authorization flow. {% hint style="warning" %} Corppass **strongly recommends** clients to use **libraries** to handle JWTs instead of attempting it themselves. See [here](https://www.jwt.io/libraries) for an overview of JWT libraries that clients can use to do so. {% endhint %} ## JSON Web Signature (JWS) JWS ensures the **integrity** and **authenticity** of data by digitally signing it. It is used to protect critical tokens like client assertions and ID tokens from tampering. A JWS consists of three components, each Base64URL-encoded and concatenated with periods (`.`): 1. **Header** – Contains metadata such as the signing algorithm (`alg`) and key identifier (`kid`). 2. **Payload** – The data or claims being signed (e.g., client ID, token expiry). 3. **Signature** – A cryptographic signature generated using the sender’s private key. ```markup .. ``` ### Usage in Corppass JWS is used to sign JWTs in the following scenarios: * **Client Assertion JWTs:** Relying Parties (RPs) send signed JWT `client_assertion` to authenticate themselves. * **ID Tokens:** Corppass signs the ID Tokens to assert that the payload is authentic and not tampered with. Corppass verifies these signatures using the public keys provided via the client’s JWKS. ### JWS Header Example ```json { "typ": "JWT", "alg": "ES256", "kid": "d591e152-886e-46cc-aa70-36a4431162a6" } ```
FieldDescription
typType of object (JWT).
algThe algorithm used for signing the JWT.
kidKey ID, used to locate the corresponding public key in the client’s JWKS.
## JSON Web Encryption (JWE) **JWE** ensures the **confidentiality** of data by encrypting it, ensuring that only the intended recipient (the RP) can decrypt and read the content. A JWE consists of five components, each Base64URL-encoded and concatenated with periods (`.`): 1. **Protected Header**: Contains metadata about the encryption algorithm (`alg`) and encryption key. 2. **Encrypted Key**: The key used to encrypt the payload. 3. **Initialisation Vector (IV)**: Ensures randomness in encryption. 4. **Cipher Text**: The encrypted payload. 5. **Authentication Tag**: Ensures integrity of the encrypted data. ``` .... ``` ### Usage in Corppass JWE is used to encrypt a signed JWT (JWS) in the following scenarios: * **ID Token:** The ID token is issued as a **Signed JWT (JWS: JSON Web Signature)** and subsequently encrypted using the RP’s public key to produce a **JWE**. * **User Info Payload:** The response payload from the `/userinfo` endpoint is issued as a **Signed JWT (JWS: JSON Web Signature)** and subsequently encrypted using the RP’s public key to produce a **JWE**. ### JWE Protected Header
FieldDescription
typType of token, usually JWT. Helps distinguish JWTs from other data types.
algThe key management algorithm used to encrypt the key that encrypts the payload.
kidKey ID used to identify which public key in the RP's JWKS should be used to perform encryption.
encContent encryption algorithm. Corppass may use A256GCM (AES-GCM with 256-bit key).
{% hint style="warning" %} JWE supports both symmetric and asymmetric encryption algorithms. Corppass only supports **asymmetric key pairs** that use **Elliptic Curve (EC)-based key agreement algorithms** to determine a common encryption key, specifically: * `ECDH-ES+A128KW` * `ECDH-ES+A256KW` * `ECDH-ES+A512KW` These algorithms use **Elliptic Curve Diffie-Hellman (ECDH)** for key agreement and **AES Key Wrapping (AxxxKW)** for content encryption. {% endhint %} {% hint style="warning" %} Clients **must** use the **`kid`** field in the JWE header to identify the client's public key, used by Corppass for encryption. {% endhint %} Refer to [RFC 7515 Section 4](https://tools.ietf.org/html/rfc7515#section-4) for more information about the JWE structure. #### Sample JWE Header ```json { "typ": "JWT", "alg": "ECDH-ES+A256KW", "kid": "nxiJJNNVxxnTkU2wL65TI2PkILIJOURSTQSABLuH2kE", "enc": "A256CBC-HS512" } ``` # Client Assertion JWT Corppass supports **JWT-based client authentication** using the mechanism defined in [RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523). Clients must generate and sign a JWT — known as a **client assertion** — and present it to Corppass when authenticating at the [PAR](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/2.-authorization-endpoint) or [Token](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/3.-token-endpoint) endpoints. This method is especially suitable for **confidential clients** that can securely manage private keys. ### When to Use A client assertion JWT must be used whenever the client authenticates with Corppass, including during: * [Pushed authorization requests](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/1.-pushed-authorization-request-par-endpoint) * [Token requests](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/3.-token-endpoint) The JWT is passed as two fields: ```markup client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer client_assertion= ``` {% hint style="warning" %} Corppass **strongly recommends** clients to use **libraries** to handle JWTs instead of attempting it themselves. See [here](https://www.jwt.io/libraries) for an overview of JWT libraries that clients can use to do so. {% endhint %} ## JWT Structure A signed client assertion JWT follows the typical JWS format: ```markup .. ``` ### JWT Header Example ```json {     "typ" : "JWT",     "alg" : "ES256",     "kid": "d591e152-886e-46cc-aa70-36a4431162a6" } ```
FieldDescription
typThe type of the token, typically set to "JWT".
algThe algorithm used for signing the JWT. Supported values are ES256, ES256K, ES384, and ES512.
kidThe Key ID associated with the signing key, matching the JWK provided during onboarding.
### JWT Claims (Payload) Example ```json { "iss": "your-client-id", "sub": "your-client-id", "aud": "https://id.corppass.gov.sg/token", "jti": "random-uuid-12345", "exp": 1712486400, "iat": 1712486100 } ```
ClaimsRequiredDescription
issYesThe client ID of the registered client.
subYesThe client ID of the registered client.
audYesThe intended audience for this JWT. Must match the issuer field (iss) from the OpenID Discovery endpoint.
jtiYes

The unique identifier for the JWT.

Prevents replay attacks. Must be unique for each JWT.

iatYesIssued-at time (epoch timestamp).
expYesThe expiration time after which the JWT is no longer valid.
{% hint style="warning" %} ## **Token Maximum Lifetime Requirement** Corppass will **reject** client assertion JWTs if the **maximum token lifespan** is more than **2 minutes.** This means that the `exp` claim must be **within 2 minutes or less** than the `iat`. This follows the best practices outlined in [Section 3 of RFC 7523](https://www.rfc-editor.org/rfc/rfc7523#section-3). RPs should ensure tokens are short-lived and avoid excessive clock skew. {% endhint %} # Proof Key of Code Exchange (PKCE) PKCE ([RFC 7636](https://datatracker.ietf.org/doc/html/rfc7636)) enhances the security of the OAuth 2.0 Authorization Code Flow by protecting against authorization code interception attacks. It is particularly important for **public clients** (e.g., mobile apps, single-page apps) that cannot securely store a client secret. ## PKCE Flow in Corppass Corppass supports PKCE as part of the **Authorization Code Flow**, requiring the client to send a **code challenge** during the authorization request and later verify it with a **code verifier** when exchanging the authorization code for tokens. ### How PKCE Works #### **Step 1: Client Generates a Code Verifier** The client generates a **high-entropy random string** between 43–128 characters for each authentication request. > Example:\ > `6I9tQd5tKn7Uy9ZfwEqd-YC71gSVfzcfVcyXLc34vQo` #### Step 2: **Client Derives a Code Challenge** The code verifier is hashed using **SHA-256** and then Base64URL-encoded to produce the **code challenge**. > Example (Base64URL of SHA-256 hash):\ > `hu0mAmPq8n91vRqudsGmriiG7blJDJS0bsDeOmEt17M` #### Step 3: Client Sends Authorization Request with Code Challenge (via PAR) The client initiates a **Pushed Authorization Request (PAR)** to the `/request` endpoint, including the following in the request body: ```http POST /request response_type=code client_id=abc123 .... code_challenge=hu0mAmPq8n91vRqudsGmriiG7blJDJS0bsDeOmEt17M code_challenge_method=S256 ``` #### Step 4: **Redirect User to Authorization Endpoint with `request_uri`** After receiving the `request_uri` from `/request`, the client must redirect the user to the `/authorize` endpoint, passing both `client_id` and `request_uri` as query parameters. > Example: > > /mga/sps/oauth/oauth20/authorize?...\&client\_id=abc123\&request\_uri=urn:ietf:params:oauth:request\_uri:h8YQPVV0Dgm5MGaD\_koAm #### Step 5: Authorization Server Responds Corppass responds with an **authorization code** upon successful user authentication. #### Step 6: Client Sends Token Request with Code Verifier The client exchanges the authorization code for an **ID token** and **access token**, providing the **original code\_verifier** to prove it generated the code challenge. > Example: > > `client_id=xyz&...&code_verifier=6I9tQd5tKn7Uy9ZfwEqd-YC71gSVfzcfVcyXLc34vQo` #### Step 7: Authorization Server Verifies Code Verifier Corppass recomputes the `code_challenge` from the received `code_verifier` and compares it to the original challenge sent in the authorization request. If they match, the token request succeeds and tokens are issued. # Demonstrating Proof of Possession (DPoP) Demonstrating Proof of Possession (DPoP) in OAuth 2.0 ensures that authorization codes and access tokens can only be used by the original client to which they were issued for. It prevents intercepted tokens/codes from being reused by attackers (replay attacks), which is especially useful for public clients like SPAs or mobile apps. This security mechanism is defined in [RFC 9449](https://datatracker.ietf.org/doc/html/rfc9449). ## How it works The DPoP mechanism enables a client to prove possession of a private key when obtaining and using both authorization codes and access tokens in a FAPI 2.0 flow. At the start of each authorization request, the client generates an ephemeral signing key pair. Using this key pair, the client creates a **signed JWT (the DPoP Proof JWT)** and sends it in the DPoP header to the authorization server. Presenting this proof demonstrates that the client holds the private key it claims to and that it is initiating the request directly. The authorization server binds the client’s presented public key to the resulting credential. * For an authorization code grant, the server binds the key to the issued authorization code, ensuring that only the client holding the private key can redeem it at the token endpoint. * For an access token, the server embeds the client’s public key into the token, restricting its use to the legitimate client with the private key. When the client later redeems the authorization code or invokes protected resource endpoints with an access token, it must again present a new DPoP proof JWT alongside its credential. The server verifies the proof and ensures that the bound credential is only usable by the same client instance that created the original request. {% hint style="warning" %} Corppass expects the DPoP proof to be provided for requests made to the [**Pushed Authorization Request**](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/2.-authorization-endpoint#step-1-sending-the-pushed-authorization-request) **endpoint,** [**Token**](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/3.-token-endpoint) **endpoint** and other **protected endpoints** (eg. [Userinfo](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/4.-userinfo-endpoint) endpoint `/userinfo` ). {% endhint %} ## Generating a DPoP Proof JWT First, clients need to generate an ephemeral signing key pair. Currently, Corppass only supports EC keys. {% hint style="warning" %} Use the same ephemeral key pair for all subsequent requests stemming from the same authentication request. {% endhint %} Next, clients need to construct the signed JWT as per the following specifications: ### DPoP Request Header The DPoP proof JWT should be base64-encoded and sent with the `DPoP` request header. {% code overflow="wrap" %} ```http DPoP: eyJhbGciOiJFUzI1NiIsInR5cCI6ImRwb3Arand0IiwiandrIjp7Imt0eSI6IkVDIiwieCI6IlBFZHFyLTFSemZ2QkZsazE0U085UkZSSm1uV2FGNlc3YlZPZ2Y3Wk9KUVkiLCJ5IjoieGVBeklzcjlTbmk1RWVnVE5xZHFZblg1V08yTm5wTHBOTXFHTEoxSjRDWSIsImNydiI6IlAtMjU2In19.eyJpYXQiOjE3NDQxODQ5ODgsImp0aSI6IjVlNmU1NTA5LTcwZTMtNGJiNy1hZDMwLTRlMTc2ZmZkM2NhOCIsImh0bSI6IlBPU1QiLCJodHUiOiJodHRwczovL2lkLmNvcnBwYXNzLmdvdi5zZy9tZ2Evc3BzL29hdXRoL29hdXRoMjAvdG9rZW4ifQ.fggiYkc6lBwIKgpZDJjSA2c3_vkrxWHxJ_7WN9RMpyqjfgOCB1Cwlvdcw7AsGNF1nDsi59s8DHUHnM6a9warbA ``` {% endcode %} ### DPoP JWT Header Structure Example of a DPoP proof JWT header: ``` { "typ": "dpop+jwt", "alg": "ES256", "jwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." } } ``` Fields in a DPoP proof JWT header:
FieldDescription
typType of token. Always set to "dpop+jwt".
algSigning algorithm. The supported values are ES256, ES256K, ES384, ES512.
jwkThe public key corresponding to the private key used to sign the JWT. Must match the key used in the DPoP-bound token.
### DPoP JWT Payload Structure Example of a DPoP proof JWT payload: ```json { "htm": "POST", "htu": "https://id.corppass.gov.sg/mga/sps/oauth/oauth20/token", "jti": "5e6e5509-70e3-4bb7-ad30-4e176ffd3ca8", "iat": 1771819829, "exp": 1771819949, "ath": "hKzf0cQEXAMPLEUXxKXJvHr_F34Pp7pg6LFaP_LZ7Jw" } ``` Fields in a DPoP proof JWT payload:
ClaimRequiredDescription
htmYesThe HTTP method of the request (e.g., POST)
htuYesThe full HTTP URI of the request (e.g., https://id.corppass.gov.sg/mga/sps/oauth/oauth20/token).
jtiYesA unique identifier for the proof. Prevents replay attacks. Must be unique for each JWT.
iatYesIssued-at time (epoch timestamp). Used to detect replayed proofs.
expNoThe expiration time after which the JWT is no longer valid.
athNo

Required only when accessing protected resource endpoints (e.g. /userinfo).

This claim contains the base64url-encoded SHA-256 hash of the DPoP-bound access token and is used to bind the proof to that specific token.

Read section below on how to compute this value.

#### How to compute the Access Token Hash (ath) claim The `ath` (Access Token Hash) claim is a **mandatory** field in the DPoP proof JWT for requests to protected resource endpoints (eg. `/userinfo`). It cryptographically binds the proof to the access token being used in a request, preventing replay attacks and misuse of tokens. **Steps:** 1. **Start with the raw access token string** you received from the [Token endpoint](/technical-specifications/corppass-authorization-api-fapi-2.0/integration-guide/3.-token-endpoint). 2. **Compute a SHA-256 hash** of the token. 3. **Base64URL-encode** the hash (no padding). **Example (Pseudo-code)** ```javascript const crypto = require("crypto"); function computeATH(accessToken) { const accessToken = "eyJhbGciOi..."; const ath = Buffer.from(crypto.createHash("sha256") .update(accessToken).digest() ).toString("base64url"); return ath; } ``` **Example Output** ```json "ath": "3rEbqHhURQcbfV3zM9sl1rsBzAcjT9TKqX3akHLZ9Nc" ``` **Example payload with `ath`** ```json { "htu": "https://id.corppass.gov.sg/authorization-info", "htm": "POST", "iat": 1712681904, "jti": "6ef56d85-e469-4bc3-a508-05d8f94f780e", "ath": "3rEbqHhURQcbfV3zM9sl1rsBzAcjT9TKqX3akHLZ9Nc" } ``` # User Guide The **Corppass Developer Portal (CDP)** is a platform that provides Relying Parties (RPs) with the tools and autonomy to onboard and manage [**Corppass Login**](/products/corppass-login) **applications** within the Corppass ecosystem. #### **Key Functions of CDP:** 1. **Onboarding New Services**\ RPs can independently onboard their digital services to Corppass. 2. **Metadata Management**\ RPs can manage metadata associated with their services, including OIDC parameters and other authorisation details. 3. **Service Publishing**\ RPs can manage and publish their services in both Staging (STG) and Production (PRD) environments. CDP gives RPs full control over their Corppass Login integration, streamlining service management, testing, and publishing while ensuring alignment with Corppass standards. # Getting Started ## Prerequisites for access 1. **NRIC/FIN Holder** * You must possess a valid NRIC/FIN. 2. **Singpass Account** * You must have an active Singpass account. * If you do not have a valid Singpass account, refer to this [FAQ](https://ask.gov.sg/singpass/questions/clul27aq60028yisxifw2l2w3?from=quicklinks) for guidance on registration. 3. **Corppass Account and Authorisation** * You must hold an active Corppass account with your organisation. If you do not, get your Corppass Admin to create an account for you. * For Corppass Admins and Sub-Admins, please refer to this FAQ for guidance on [how to create a Corppass account](https://ask.gov.sg/corppass/questions/cm1q0y3r4006xwdnwn8nr7kk2?from=search) for other users. * You must also be authorised to access the "Corppass Developer Portal" digital service. * For Corppass Admins and Sub-Admins, please refer to the [FAQ on User Authorisation](https://ask.gov.sg/corppass/questions/cm1q0y3qv0033wdnw6z89qxcq?from=search) to grant CDP access to other users in your organisation. *** ### Locating Your Corppass Admin If you are unsure who your Corppass Admin is, refer to this [FAQ on Finding Your Corppass Admin](https://ask.gov.sg/corppass/questions/cm1q0y3r00053wdnwc1hjxu0j?from=search) for assistance. *** ### If you already have "Default Access to all Digital Services" * You will automatically have access to CDP if your Corppass account has previously been configured with '*Default access to all digital services'*. ([how to check](https://ask.gov.sg/corppass/questions/cm6ryazs90071aqz9wufc39qe)) * Please note however, that your default role on CDP will be **'Read-Only User'** in this case. Learn more about [roles in CDP](/corppass-developer-portal-cdp/user-guide/portal-features/user-roles-and-permissions) and their respective permissions. * If you need a higher access level, you will need your entity's Corppass Admin / Sub-Admin to authorise you for CDP and change the role assignment. # Login to CDP To access the Corppass Developer Portal (CDP), you must have an active Corppass account under your organisation and the necessary authorisation for the digital service. ## Step-by-Step Login Guide ### 1. Visit the Portal * Go to [**https://developer.corppass.gov.sg**](https://developer.corppass.gov.sg) * Click **"Log in with Singpass"**.
*** ### 2. Authenticate with Singpass * Follow the Singpass authentication process - you will be logging in as a 'Business User'.
*** ### 3. Select Your Entity * After successful authentication, you may be prompted to select the entity you want to transact for. * This selection page will not appear if you are authorised to transact for only one entity. * Click on the **Entity Name (UEN)** you are transacting for.
*** ### 4. Access the Dashboard * You will be redirected to the **CDP Dashboard**. * By default, the dashboard displays all **staging apps** for the selected entity. * "See nothing?" - It's time to [Create a New Service](/corppass-developer-portal-cdp/user-guide/portal-features/digital-service-configuration) *** ### Additional Notes * Ensure your Corppass account is correctly authorised for the entity you wish to transact on behalf of. * For support, contact your organisation's Corppass Admin. # Portal Features {% content-ref url="/pages/o6kgBlsKwDY1fCl7opUY" %} [Dashboard](/corppass-developer-portal-cdp/user-guide/portal-features/dashboard) {% endcontent-ref %} {% content-ref url="/pages/jgpobxcy9Ln7YVlAcM8K" %} [Digital Service Configuration](/corppass-developer-portal-cdp/user-guide/portal-features/digital-service-configuration) {% endcontent-ref %} {% content-ref url="/pages/bLnP0a4k8qZUCPVTHCt6" %} [Creating Digital Service](/corppass-developer-portal-cdp/user-guide/portal-features/creating-digital-service) {% endcontent-ref %} {% content-ref url="/pages/BraTpbU7dvBZhWEldTPF" %} [Managing Digital Service](/corppass-developer-portal-cdp/user-guide/portal-features/managing-digital-service) {% endcontent-ref %} {% content-ref url="/pages/HV5USocXxl8VTbbflbWl" %} [User Roles and Permissions](/corppass-developer-portal-cdp/user-guide/portal-features/user-roles-and-permissions) {% endcontent-ref %} {% content-ref url="/pages/WDj5a2UfKhFHti3cMViq" %} [Staging and Production Environments](/corppass-developer-portal-cdp/user-guide/portal-features/staging-and-production-environments) {% endcontent-ref %} # Dashboard The Dashboard provides a comprehensive view of all available [Corppass Login](/products/corppass-login) applications for your entity. From here, you can: * View all the Corppass Login applications linked to your entity. * Create a new digital service for Corppass Login. # Digital Service Configuration Before initiating the configuration of your digital service for Corppass Login in the Corppass Developer Portal (CDP), ensure that the following details are gathered. This preparation will help streamline the setup process and ensure alignment with your organisation’s requirements. ### 1. OIDC Parameters * **Callback URL**: * The URL where your digital service will receive responses from Corppass after authentication. * Multiple callback URLs can be associated with each service if required. * Ensure that these URLs are registered correctly and accessible by your application. * **JWKS Endpoint or Object**: * JWKS provides a secure method to share public keys for verifying JSON Web Tokens (JWTs). * This must contain both signing keys (for Client Assertion / DPoP) and encryption keys (for ID Tokens). * Each digital service is linked to a unique Client ID, meaning only one JWKS endpoint or object is permitted per service. * The endpoint must be securely hosted and accessible by Corppass for token verification. ### 2. [Entity Types](/corppass-developer-portal-cdp/user-guide/faq/digital-services#what-are-the-allowed-entity-types-for-a-digital-service) Consider the types of entities that will be authorised to access and transact using your digital service. ### 3. [Entity Statuses](/corppass-developer-portal-cdp/user-guide/faq/digital-services#what-are-the-allowed-entity-statuses-for-a-digital-service) Identify the statuses that your digital service will permit. ### 4. Third-Party Transactions Decide whether the digital service will allow third-party entities to transact on behalf of their clients. ### 5. Foreign Entities Determine whether the digital service will support transactions by foreign entities. ### 6. Additional Parameters If applicable, prepare any additional details required for the digital service. * **Sub-UEN**: Sub-entity identifiers for more granular access control. * **Roles**: Role definitions for assigning specific user permissions. * **Custom Parameters**: Any other custom parameters relevant to the service. {% hint style="warning" %} Please note that some of these configurations cannot be modified after a digital service is published. Refer to this [section](/corppass-developer-portal-cdp/user-guide/faq/digital-services#what-settings-cannot-be-changed-after-publishing-the-digital-service) for more details. {% endhint %} ### 7. Test the Service in the Staging Environment Before proceeding to the production environment, it is essential to test the service in the Staging environment. This ensures: * The configurations are functioning correctly. * Security and authentication protocols are working as expected. * Integration tests are conducted to resolve any potential issues. ### 8. Create Digital Service in the Production environment and update Billing Information After the digital service has been fully configured and tested in the Staging environment, create the service in the Production environment. The status will be set to **"Reviewing."** Please provide your billing details at this stage. Once the billing details are submitted, the Corppass team will review and approve the service. The status will then change to **"Inactive."** The RP can decide when to activate the service after completing the necessary configuration. Note: You are not required to upload the approval email, as having a Corppass account with the 'admin' role to the 'Corppass Developer Portal' (CDP) service confirms your eligibility to onboard and publish a service. # Creating Digital Service ## Digital Service Onboarding Follow the steps outlined in the portal to successfully onboard a new digital service. The onboarding process includes: 1. **Creation of a New Digital Service**: * Enter the required details, such as the service name, description, and metadata. 2. **Approval Process:** * Once submitted, the service request will be reviewed and approved by **GovTech personnel**. * Once the request is approved, its status will be set to '**Inactive'**. 3. **Post-Approval Configuration:** * After approval, you can configure additional settings: * Determine whether the service requires additional checks from the agency. * Define which entity types are permitted to use the service. * Specify if foreign entities are allowed to transact with the service. 4. **Authorisation Metadata (Optional):** * You can add the following authorisation metadata to the service: * **Sub-UEN** * **Roles** * **Parameters** ## Publishing the Digital Service * After completing the onboarding and approval process, you can publish the digital service by clicking the **'Activate'** button. This action will change the status of the service to **Active**, making it available for use. * **Note:** If you need to suspend the service for any reason (e.g., security concerns or fraud), you can deactivate it by clicking the **'Deactivate'** button. This will change the status of the digital service to **'Inactive'**, effectively halting its use until it is reactivated. # Managing Digital Service The Corppass Developer Portal allows you to manage the metadata associated with your digital services, ensuring that your services remain up-to-date and accurate. This includes the ability to add, update, or delete metadata entries related to your digital service. ## Updating the Digital Service You can update the details of an existing digital service at any time. This includes: * **Service Name** * **Description** * **Metadata** Updates to these fields can be made directly in the portal and do not require additional approval. The **agency admin** is responsible for managing any changes to the digital service data. ## Managing Metadata The portal also allows you to manage the metadata linked to your digital services. This includes: * **the OIDC Parameters** * **advanced settings** * **authorisation metadata** ### Note: **Once a digital service is published and in an 'Active' state**, certain configurations cannot be modified as entity users' explicit authorizations are tied to them: * **UEN Entity Types**: Once allowed, they cannot be removed. * **Parameters**: Once published, they cannot be added, edited, or removed. * **Roles**: Once published, they cannot be added, edited, or removed. Ensure all configurations are carefully reviewed before publishing. # User Roles and Permissions This page provides an overview of the roles available in the Corppass Developer Portal (CDP) and the associated permissions for each role. ## Role Definition in CDP All authorised users to CDP will have '**View**' access to all the digital services under their entity. 1. **Admin User\***: * Full permissions to read and modify all **staging** and **production** digital services within the entity. * This role is suitable for users responsible for end-to-end management of digital services. 2. **Staging Admin User**: * Allowed to **view** both **staging** and **production** digital services. * Can only **modify staging** digital services under the entity. * Ideal for users handling testing or pre-production environments. 3. **Read Only User**: * Restricted to **view-only** access for digital services registered under the entity. * Cannot modify any digital services settings. * Suitable for users who need visibility but do not require editing permissions. *\*This is the CDP Admin role, not to be confused with "Corppass Admin".* The table below gives an overview of the differences in access rights for roles on CDP.
RolesDescriptionModify STGModify PRD
Admin UserThis user role will be able to view and modify the digital services within their agency.YY
Staging Admin UserThis user role will be able to view the digital services in their agency across STG and PRD but can modify them only in STG.YN
Read Only UserThis user role can only view the digital services in both STG and PRD for their agency.NN
# Staging and Production Environments Corppass Developer Portal allows you to toggle between Staging and Production environments. To toggle between the environments: 1. Click on **"Working with mock data in Staging"** to view the Staging environment. 2. Click on **"Working with live data in Production"** to switch to the Production environment. # FAQ {% content-ref url="/pages/sXEWS1WuE2vpft0Mx05J" %} [Login Issues](/corppass-developer-portal-cdp/user-guide/faq/login-issues) {% endcontent-ref %} {% content-ref url="/pages/hiFzYMDVPpcQB08iC5gb" %} [Access and Permissions](/corppass-developer-portal-cdp/user-guide/faq/access-and-permissions) {% endcontent-ref %} {% content-ref url="/pages/sAAwYUg9EgvGtWIvJXrc" %} [Digital Services](/corppass-developer-portal-cdp/user-guide/faq/digital-services) {% endcontent-ref %} {% content-ref url="/pages/5danJGkth46Nwu4IXJaK" %} [How is CDP Different from Corppass Agency Admin (AA) Portal?](/corppass-developer-portal-cdp/user-guide/faq/how-is-cdp-different-from-corppass-agency-admin-aa-portal) {% endcontent-ref %} {% content-ref url="/pages/5kxTFDXmrMn3PJSPmgyM" %} [Other Common Issues](/corppass-developer-portal-cdp/user-guide/faq/other-common-issues) {% endcontent-ref %} # Login Issues ### I cannot log in to the Corppass Developer Portal (CDP). What should I do? Follow these steps to troubleshoot your login issue: 1. Ensure your Singpass account is active and you are logging in as a "Business User." 2. Confirm that your Corppass account is authorised to access the CDP digital service. * If you're unsure, refer to the [FAQ on Corppass authorisation.](https://ask.gov.sg/corppass/questions/cm1q0y3r8008pwdnws9oepc2f?from=topics) * If you do not have the necessary permission to access CDP, please contact your entity's Corppass Admin for assistance in updating your access. *** ### I am logged in to the Corppass Developer Portal (CDP), but I cannot see any digital service(s). What should I do? #### Follow these steps to troubleshoot: 1. Ensure you are accessing the correct environment (Staging or Production). 2. Confirm that your entity's Corppass Admin has assigned the required roles to your account to view or manage digital services. * If you're unsure, refer to the [FAQ on Corppass authorisation.](https://ask.gov.sg/corppass/questions/cm1q0y3r8008pwdnws9oepc2f?from=topics) * If you do not have the necessary permission to access CDP, please contact your entity's Corppass Admin for assistance in updating your access. # Access and Permissions ### How do I know if I have the right role assigned in CDP? 1. Refer to the '[User Roles and Permissions](https://docs.corppass.gov.sg/corppass-developer-portal-cdp/user-guide/user-roles-and-permissions)' page to understand the differences in permissions allowed for each CDP role. 2. Refer to this [FAQ on Corppass authorisation](https://ask.gov.sg/corppass/questions/cm1q0y3r8008pwdnws9oepc2f?from=topics) to check if you are assigned the required role to perform the transaction. * If you do not have the necessary permissions to access CDP, please contact your entity's Corppass Admin for assistance in updating your access. *** ### What should I do if I need additional permissions? 1. Contact your Corppass Admin to request the necessary permissions or role updates. 2. If you are unsure who your Corppass admin is, please refer to the [FAQ on Finding Your Corppass Admin](https://ask.gov.sg/corppass/questions/cm1q0y3r00053wdnwc1hjxu0j?from=search) for assistance. # Digital Services ### Why am I unable to view the 'Corppass Developer Portal' service in the Corppass Digital Service List (DGL)? The 'Corppass Developer Portal' service is not displayed in the DGL as it is specifically intended for Relying Parties (RPs) and is not and is not accessible for entity use. *** ### What is the purpose of the "Entity Types" field? The "Entity Types" field ensures that only entities of the selected types are permitted to transact with the digital service. For example, if the 'Hospitals' entity type is not selected, it means that entities with the "Entity Type = Hospitals" will be restricted from accessing the digital service. *** ### What are the allowed entity types for a digital service? \ The following is the list of entity types allowed to transact with the digital service onboarded to Corppass: 1. Bank Representative Offices 2. Both Medical and Dental Clinic 3. Businesses 4. Charities and Institutions of a Public Character 5. Clinical & X-ray Laboratories 6. Clinical Laboratories 7. Commercial Home 8. Consulate-General or Consulate 9. Cooperative Societies 10. Foreign Companies 11. Foreign Law Practice Representative Offices 12. Foreign Military Units 13. Government and Government-Aided Schools 14. Grassroot Units 15. High Commissions or Embassies 16. Hospitals 17. Insurance Representative Offices 18. International Education Language Centres 19. International Organisations 20. Limited Liability Partnerships 21. Limited Partnership 22. Local Companies 23. Madrasahs 24. Management Corporations 25. Maternity Homes 26. Mosques 27. Mutual Benefit Organisations 28. News Bureaus 29. Only Dental Clinic 30. Only Medical Clinic 31. Organs of State, Ministries and Departments 32. Other Financial Representative Offices 33. Other Organisation 34. PA Services 35. Public Accounting Firms 36. Representative Office 37. Societies 38. Statutory Boards 39. Subsidiary Management Corporations 40. Town Councils 41. Trade Representation Office 42. Trade Unions 43. Variable Capital Companies 44. Voluntary Welfare Home 45. X-ray Laboratories *** ### What are the allowed entity statuses for a digital service? * **Registered**: The entity is officially registered with ACRA and recognised as an active business. * **Deregistered**: The entity has been formally removed from ACRA’s register, either voluntarily or due to non-compliance. * **Withdrawn**: The entity has voluntarily ceased its business operations and notified ACRA accordingly. *** ### Can the entity type be changed after publishing the digital service? Once UEN entity types are allowed for a published digital service, they cannot be removed. Please ensure that the options are carefully considered and confirmed prior to publishing the digital service. *** ### What settings cannot be changed after publishing the digital service? Once the digital service is published, the following settings cannot be modified: 1. **Allowed entity types**: * Once UEN entity types are allowed for a published digital service, they cannot be removed. 2. **Allowed entity statuses**: * Once UEN entity statuses are allowed for a published digital service, they cannot be removed. 3. **Sub-UEN authorisation metadata:** * The Sub-UEN format cannot be modified after a digital service is published 4. **Roles:** * Roles cannot be modified or removed after a digital service is published * New roles can be added, but cannot be modified or removed upon saving * If a published digital service has no roles, new roles cannot be added 5. **Parameters:** * Parameters cannot be modified or removed after a digital service is published * New mandatory parameters cannot be added * New optional parameters can be added, but cannot be modified or removed upon saving *** # How is CDP Different from Corppass Agency Admin (AA) Portal? ### Changes in Access and Role Management * Partners can now manage their own access to CDP independently, eliminating the need to wait for Corppass team to create or manage Agency Admin accounts. * Once authorised, access rights are granted to all digital services tagged to a user's organisation/agency, unlike Agency Admin Portal which granted access at a per digital service level. * Different role types on CDP allow varying level of permissions to users. Visit [User Roles Guide](https://docs.corppass.gov.sg/corppass-developer-portal/user-roles-and-permissions) for more details on what access rights each role has. * Notably, users assigned with the **Admin** role in CDP can view and edit all digital service(s) tagged to their organisations/agencies. ### Changes in Process of Publishing/Unpublishing a Service * Activating/publishing a service in the Staging environment will not require any approval. * However when you activate/publish a digital service in the Production environment for the first time, this will trigger a review of your service by GovTech-authorised personnel. * You are no longer required to upload an approval email, as having a Corppass account with the 'Admin' role for the 'Corppass Developer Portal' (CDP) service confirms your prior authorisation to onboard and publish a service. * (no change) You may deactivate your active digital services on CDP (no approval process). ### Changes for Deletion of Service * Since deletion of a service is an irreversible action, we are no longer availing this as a self-serve feature to avoid unintended consequences. Partners are to **raise a service request** through the [Partner Support Portal](https://partnersupport.corppass.gov.sg/hc/en-sg). ### Changes on roles/parameters post-publishing of a service 1. In CDP's current state, roles and parameters **cannot be changed / added after a service is published for the first time.** In particular, 1. Entity types and/or statuses - can be added, but cannot be removed 2. Sub-UEN settings - cannot be changed 3. Roles and parameters - cannot be added or removed 2. The following operations can be done on the Agency Admin portal, if needed: 1. Add role 2. Delete role (*NOTE: this is a destructive action and will irreversibly remove all existing user assignments with that deleted role which Corppass Admins of various entities have authorised to your service previously. Corppass does not send out notifications to the affected users or Corppass Admins for such changes.)* 3. Add Parameter 1. Any parameters added *after* service has been published should be marked as *optional*. 2. Whilst allowed, adding new mandatory parameters after your service has been published may cause existing authorisations to fail on your end (especially if you're enforcing checks on the payload that Corppass returns to you), and is not recommended. # Other Common Issues ### How long will it take for my application to be approved? * The approval of your application will take up to three working days. *** ### I see an "Unauthorised" error after logging in. What does this mean? * This typically means your Corppass account is not authorised for the CDP digital service. Contact your Corppass Admin to request the necessary permissions. * If you are unsure who your Corppass admin is, please refer to the [FAQ on Finding Your Corppass Admin](https://ask.gov.sg/corppass/questions/cm1q0y3r00053wdnwc1hjxu0j?from=search) for assistance. *** ### How can I switch between Staging and Production environments? * Use the environment toggle at the top of the dashboard. If the toggle is unavailable, ensure your role grants access to both environments. *** ### I am unable to activate a digital service. What should I check? * Confirm that your entity's Corppass Admin has assigned the required roles to your account to manage digital services. * If you have the necessary permissions, after submitting the creation of a new digital service, your service request will need to be reviewed and approved by GovTech personnel. * Once approved, your application status will be set to 'Inactive,' and you can then configure additional settings and activate or publish your digital service. *** ### Can I continue to use the Corppass Agency Admin (AA) portal? How long will the AA Portal remain operational? Yes, you may continue using the AA portal, which will remain operational until 30 June 2025. During this transition period, both the AA portal and the CDP will operate in parallel to facilitate a smooth migration and support ongoing administrative processes. Any updates made in either the CDP or AA portal will take effect accordingly. However, Relying Parties (RPs) are strongly encouraged to adopt the CDP as soon as possible, as it provides a more user-friendly interface and enhanced self-service features to improve efficiency. # What You Need to Know Before Onboarding a Digital Service in Corppass # Important things to note # JWKS Configurations ### **What algorithm should I use for signing JWTs?** * Corppass only supports **EC (Elliptic Curve) algorithms** for signing. * Supported curves: **P-256, P-384, P-521**. * Example algorithm: **ES256 (EC Signature with SHA-256)** Ensure that your JWKS configuration specifies the `alg` field correctly and matches one of the supported EC algorithms.​ *** ### **What is the required format for the JWKS Object?** The JWKS Object must conform to the RFC 7517 specification and include the following attributes: * **kid (Key ID):** Unique identifier for the key. * **kty (Key Type):** Type of key (**EC for signing**, EC or RSA for encryption). * **use (Usage):** Indicates the key’s purpose (`sig` for signing or `enc` for encryption). * **alg (Algorithm):** Specifies the algorithm (e.g., `ES256` for signing, `ECDH-ES+A256KW` for encryption). * **Key-specific attributes:** * For **EC keys** (Elliptic Curve): `crv` (curve), `x`, and `y`. * For **RSA keys** (encryption only): `n` (modulus) and `e` (exponent). We recommend relying parties (RPs) use a **publicly accessible endpoint** that contains your application's public keys in JWKS format. If you need Corppass to host the JWKS Object, please submit a service request via Partner Support. *** ### **What should I do if JWT validation fails?** * Verify the `kid` in the JWT header matches a key in the JWKS Object or Endpoint. * Check the `alg` field in the JWT and ensure it aligns with the expected algorithm. * Ensure your public key matches the private key used for signing. *** ### **What is the lifetime for Corppass tokens?** Tokens issued by Corppass have the following lifetimes: * **Authorisation Code**: 10 minutes * **ID Token**: 10 minutes * **Access Token**: 10 minutes *** ### **What if I can't expose my JWKS endpoint publicly?** Corppass requires that client JWKS endpoints be **publicly accessible** to ensure smooth key verification. However, if exposing your JWKS endpoint publicly raises security concerns for your organisation, **you may request Corppass to host the JWKS Object** instead. Submit a request via [Partners Support Centre](https://partnersupport.corppass.gov.sg/hc/en-sg) for assistance in setting this up. *** ### **Can I configure both a JWKS Endpoint and a JWKS Object for the same service?** No, Corppass supports only **one** option — Relying Parties can submit either a JWKS Endpoint or a JWKS Object — for each service. # Key Rotation ### **How do I rotate my JWKS keys?** The process for rotating your JWKS keys depends on where they are hosted: **If your JWKS is hosted on your own endpoint:** * You can rotate your keys **at any time** without notifying Corppass. * Ensure your system dynamically recognizes the new keys by using the `"kid"` (Key ID) field. **If your JWKS is stored as a JWKS Object with Corppass:** 1. **Submit your new keys** to Corppass for an update. 2. Corppass will **add the new keys to the keyset** while temporarily retaining the old keys. 3. Ensure your application dynamically selects the correct key for decryption using the `"kid"` field. 4. **Test the new keyset** to confirm successful integration. 5. Once verified, Corppass will **remove the old keys** from the system. By following this process, you ensure a smooth key transition without service disruptions. *** ### **What should I do if my encryption key needs to be rotated?** To ensure zero-downtime key rotation, follow these steps: 1. **Generate a new encryption key pair (K2)** while keeping the existing key (K1) active. 2. **Add K2 to your JWKS** while retaining K1. 3. **Wait at least 1 hour** to allow Corppass to retrieve the new key. 4. **Verify that Corppass is using K2** before removing K1 from the JWKS. This process ensures that encryption remains uninterrupted during the transition. *** ### **Does Corppass require both signing and encryption keys?** Yes, Corppass requires both: * A **signing key (EC)** for validating client assertions. * An **encryption key (EC or RSA)** for encrypting ID tokens. ⚠ **Note:** RSA encryption keys are **deprecated** but still supported for backward compatibility. New implementations should use EC encryption keys. # Callback URLs ### **Can I configure multiple Callback URLs?** Yes, you can configure multiple Callback URLs for a single digital service. The `redirect_uri` in the authentication request must match one of the registered Callback URLs **exactly**, including the protocol (`https://`). *** ### **What happens if my Callback URL is incorrectly configured?** If the `redirect_uri` parameter in your request does not exactly match one of the registered Callback URLs, Corppass will reject the request with an **invalid\_request** error. Always ensure that the Callback URL is accurate and properly registered in both staging and production environments. *** ### **Can I use a wildcard in the Callback URL?** No, wildcard characters (e.g., `*`) are not allowed in the Callback URL. Each Callback URL must be explicitly defined in the service configuration. *** ### **Can I update the Callback URL after onboarding?** Yes, updates to Callback URLs is allowed. However, all changes should be tested in the staging environment before applying them to production. *** ### **Are there any keyword restrictions for Callback or JWKS URLs?** Yes, both Callback and JWKS URLs cannot contain the words 'singpass', 'corppass', or 'myinfo' as part of efforts to combat scams. # TLS Certificates ### **What should I do to prevent service disruptions due to Corppass certificate rotation?** To avoid disruptions: * **Do NOT pin Corppass TLS leaf certificates.** These certificates are rotated periodically without prior notice. * **Ensure your system trusts AWS root CA certificates.** The trusted certificate chain can be found in the [AWS Trust Repository](https://docs.aws.amazon.com/acm/latest/userguide/acm-certificate.html). By following these steps, your system will remain compatible with Corppass certificate updates. *** ### **How should I handle certificate validation for Corppass?** It is recommended for Relying Parties to trust all certificates issued by established Certificate Authorities (CAs). Amazon Web Services (AWS) is Corppass's issuing CA. Add AWS root certificates to your trust store, available at the [AWS Trust Repository](https://www.amazontrust.com/repository/), to ensure uninterrupted service. *** ### **Why is TLS certificate pinning not recommended for Corppass?** Pinning TLS leaf certificates is not recommended because Corppass certificates are regularly rotated or re-issued. If your system relies on pinned certificates, this will result in a service disruption. Corppass rotates its certificates as a routine maintenance activity without prior notification. As such, we highly recommend Relying Parties not to pin our leaf certificates. # Whitelisting Corppass IP Addresses for Outgoing Traffic ## **Why can't I whitelist Corppass IP addresses for outgoing traffic?** For enterprise networks or networks with restricted traffic, it's common for system administrators to configure a whitelist of outgoing traffic. However, Corppass advises against whitelisting IP addresses and recommends whitelisting by domain instead. Here's why: * **Corppass operates on AWS**: Corppass uses CloudFront, which relies on a large and dynamic pool of IP addresses to ensure high availability of services. This list of IP addresses can change periodically. * **IP addresses may change**: If you whitelist Corppass endpoints by IP address, there's no guarantee that these addresses will remain static. Changes in IP addresses can cause disruptions, preventing your e-service from accessing Corppass. Therefore, whitelisting by domain is always the preferred and more reliable method. *** ### **Can I still use IP address whitelisting for Corppass?** If you must use IP address whitelisting, refer to the following AWS CloudFront resources: * [AWS CloudFront Edge Server Locations](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html) * [List of CloudFront IP Addresses](https://d7uri8nf7uskq.cloudfront.net/tools/list-cloudfront-ips) However, please note that using these resources may still result in disruptions due to changes in IP addresses over time. # Other issues ### **How can Relying Parties (RPs) retrieve the user's Full Name?** The process depends on the type of user: * **NRIC/FIN Users:** The Full Name is retrieved from **Corppass Identity Claims** during authentication. * **Foreign ID Users:** The Full Name is manually provided by **Corppass Admins or Sub-Admins** when the user's account is created. Ensure your integration correctly extracts the Full Name from the appropriate claim in the authentication response. # Myinfo Business Test Personas We provide a set of Myinfo Business test personas with diverse attributes and metadata to help you simulate different user and entity profiles when testing your Myinfo Business integration. These test personas are intended **solely for Myinfo Business** data retrieval and verification testing. #### ⚠️ Important Usage Notes * **Do not** use these test personas for **Corppass Login** applications. * If you need test accounts for Login flow testing, please refer to this [article](https://partnersupport.corppass.gov.sg/hc/en-sg/articles/49809641612185-I-need-staging-test-account-for-Corppass-testing). * Test persona details may change over time. * The profile data associated with these personas is valid only at the time of testing. We will update, modify, or refresh persona attributes periodically without prior notice. * Do not hardcode values. * Your integration should not rely on fixed persona attributes (e.g. names, emails, addresses) and should handle changes gracefully. #### How to use the test personas {% hint style="info" %} These test profiles and credentials are provided to support Myinfo Business test flows only, and should not be used for production or Login application validation. {% endhint %} 1. Select a Corppass Account from the **`mib_testprofile_corppass_accounts`** CSV file according to your testing needs. 1. The persona attributes of the **Person** tied to the Corppass Account can be obtained by looking up the **`uinfin`** value in the **`mib_testprofile_person`** CSV file. 2. The persona attributes of the **Entity** tied to the Corppass Account can be obtained by looking up the **`Entity Registration Number (UEN)`** value in the **`mib_testprofile_entities`** CSV file.
2. To login as the selected Corppass Account, 1. Use the following credentials during Singpass Login: > Username: \[UINFIN value of selected account] > > Password: `Userinfo@2024` 2. For Corppass Accounts that are associated multiple entities, select the desired entity during the Corppass UEN selection page. #### Test Persona Files Download the full list of test personas below: {% file src="/files/ayDgTgGA9RpvX0qjEYIX" %} # Contact Us #### For Corppass Partners If you have any queries or require support, please submit a request via [Partner Support Portal](https://partnersupport.corppass.gov.sg/). #### For Corppass Entity Users If you are an entity user of Corppass, you may access support via the [Corppass Contact page](https://www.corppass.gov.sg/corppass/common/contactus).