Singpass integration for Singapore web and mobile apps: login, Myinfo auto-fill and FAPI 2.0

What is Singpass integration, in plain terms?

Singpass integration is connecting your website or app to Singpass, Singapore's national digital identity, so users can sign in with it and, if you use Myinfo, share verified personal data with you after giving consent. Under the hood it follows OpenID Connect, the same family of standards behind many “sign in with” buttons, with extra security from the FAPI 2.0 Security Profile.

There are two main products. Singpass Login authenticates the user and tells you who they are. Myinfo goes further and, with the user's consent, returns specific data items your application is approved for, such as name, address or other details, so forms fill themselves. For users acting on behalf of a company, Myinfo Business returns company data and now runs on the Corppass authorisation API.

Why businesses want Singpass integration: fewer typing errors, less document handling, faster onboarding and data that comes from government sources rather than from a phone photo of a card. The trade-off is an approval process, stricter technical requirements than a social login, and responsibility for protecting the data you receive.

Who can use Singpass integration, and what do you need first?

A Singapore-registered entity, onboarding with its own UEN through Corppass. According to the Singpass developer documentation, organisations in regulated industries may need to provide their licences or permits, and applications should request only the data directly needed, with justification for each Myinfo scope, user consent and an alternative for people who cannot use Singpass.

That last point shapes your product. Tourists, many foreign workers and overseas customers do not have Singpass, so a Singpass integration normally sits beside another sign-up path rather than replacing it.

This is also why we cannot apply on your behalf. The Singpass application, the service agreement and the production client belong to your company. Our role starts once your Corppass administrator has granted Singpass Developer Portal access to someone in your team, who can then create the staging app we build against.

• Company UEN and a Corppass administrator who can grant portal access.
• A clear use case: why you need Singpass Login, and why each Myinfo item.
• Any licence or permit relevant to your regulated activity.
• A non-Singpass path for users without Singpass.
• A privacy notice and data handling plan for what you receive.

How does onboarding on the Singpass Developer Portal work?

In short: portal access through Corppass, a staging app, testing, a production app with scopes and a user journey, then approval and activation. The Singpass documentation describes the steps for private companies roughly as follows.

• Get Corppass authorisation under your UEN and request Singpass Developer Portal access from your Corppass admin.
• Log in to the portal and select your company's UEN.
• Create a staging application with the right product (Singpass Login or Myinfo) and scopes.
• Build and test the integration in the staging environment.
• Switch the portal to production and accept the Singpass service agreement if you do not already have one.
• Create the production app, choose the Myinfo data scopes (openid is mandatory) and upload your user journey document.
• Submit for approval; once approved, the production app is activated and its client ID works.

The documentation says production approval may take up to two weeks. For Singpass integration projects, we plan the build so that staging work finishes, and the user journey document is ready, well before your launch date, leaving room for questions from the Singpass team.

Singpass Login, Myinfo or Myinfo Business: which do you need?

Choose Singpass Login when you only need to know that the user is who they say they are; add Myinfo when you need verified personal data for a form; use Myinfo Business when the user is acting for a company and you need company data.

A tenant portal for an existing landlord might only need Login. A financial services application form, where accurate personal details matter, might use Myinfo to pre-fill them. A B2B onboarding flow for trade accounts might use Myinfo Business so the company's registered details arrive verified.

Singpass's documentation notes that Myinfo Business v3 is built on the Corppass authorisation API with FAPI 2.0, and that a new Myinfo Business v3 app is created on the Singpass Developer Portal; older client IDs are not interchangeable with it. If your Singpass integration mixes personal and business flows, we map which screens use which product before any code is written.

How does the Singpass FAPI 2.0 login flow work technically?

Your server first pushes the authorisation request to Singpass over a back channel, the user authenticates in Singpass, and your server exchanges the returned code for tokens using proof that it holds specific keys. According to the Singpass integration guide, the flow uses Pushed Authorization Requests, PKCE, DPoP and signed client assertions.

Singpass recommends OpenID-certified relying party libraries rather than hand-written cryptography, and we follow that advice in every Singpass integration we build.

Do existing Singpass integrations need to migrate to FAPI 2.0?

Yes. Singpass's developer documentation states that all Singpass APIs must be fully compliant with FAPI 2.0 by 31 December 2026. If your integration was built before these requirements, it likely needs changes before that date.

The good news, according to the same documentation, is that because Singpass was already OIDC-compliant, migration usually means updating parts of the integration rather than rebuilding it. Typical changes are adding the PAR step, switching to PKCE with S256, adding DPoP proofs to token and userinfo calls, and updating client authentication.

For a migration, we start by reading your current code and configuration, list the exact gaps, test the updated flow in staging and plan a production switch that does not log everyone out at once. Leave time: approvals and testing on your side, plus any app store review for mobile apps, can stretch a small code change into several weeks.

How does Singpass integration work in a mobile app?

The app sends the user to Singpass and receives them back through a redirect URL that the app has claimed as its own. Singpass's documentation says native apps should use app-claimed HTTPS URLs, meaning Universal Links on iOS and App Links on Android, not custom URL schemes.

That requirement closes a known gap: with custom schemes, another app on the phone could register the same scheme and intercept the redirect. Claimed HTTPS links are verified against files hosted on your domain, so only your app receives the response.

We build mobile apps in Flutter or React Native and keep the sensitive steps, such as the client assertion and token exchange, on your backend rather than in the app, since anything shipped in an app can be extracted. The app handles the user journey; the server holds the keys. Mobile builds with Singpass integration start at US$600, and our mobile app development page covers publishing on both stores.

Which Myinfo data scopes should you request?

Only the ones your process genuinely needs, with a reason for each. Singpass's onboarding guidance asks for justification per scope, and requesting less makes approval smoother and your data protection burden lighter.

We work through your form field by field: does this field need a verified value, or would the user's own entry do? Is a full date of birth required, or only confirmation of age? Must you keep the NRIC number, or only confirm that the person is who they claim to be? Each “no” removes a scope, a column in your database and a risk.

The user journey document you upload with the production app should show where each item is used. We help draft it with screenshots from staging, so the Singpass team sees exactly what the user sees. A Singpass integration that asks for five well-justified items is easier to explain, maintain and protect than one that asks for twenty just in case.

What happens to customers who already signed up with email?

They link their existing account to Singpass once, after proving they own it, and from then on can sign in either way. Getting this step right matters more than the login button itself, because a careless design creates duplicate profiles or, worse, lets one person take over another's account.

Our usual pattern: an existing customer signs in with their password as normal, opens account settings and chooses to connect Singpass. After the Singpass round trip, the stable identifier Singpass returns for that person is stored against their account. Next time, choosing Singpass finds the linked account directly. We never link accounts automatically by matching names or email addresses, since those are not unique enough to trust.

New customers who start with Singpass get an account created on the spot, with any approved Myinfo items filled in. If someone later tries to register by email with details that look like an existing Singpass-linked profile, the system asks them to sign in instead of creating a second record. Support staff get a simple screen to unlink an identity when a customer asks, with the action written to the audit log.

How much does Singpass integration cost?

There are two parts: the build and Singpass's own charges. With BtechWaleTech, custom web apps with Singpass start at US$900 and mobile apps at US$600; adding Singpass to an existing system or migrating to FAPI 2.0 is quoted after a code review. Singpass's transaction pricing is shown in the Singpass Developer Portal and billed to your company.

Quotes for Singpass integration vary widely because the Singpass part is only one piece. Connecting a login button to a fresh app is modest. Linking Singpass identities to existing customer accounts, handling people who already signed up by email, adding Myinfo to several forms, supporting both web and mobile and passing a security review is considerably more.

Ask any developer what their quote includes: staging and production setup, key management, account linking, Myinfo mapping, the non-Singpass path, user journey documentation, security testing and maintenance. Missing items tend to reappear later as change requests.

• Login only, or Login plus Myinfo or Myinfo Business.
• New application, or integration into existing accounts and sessions.
• Web only, or web plus iOS and Android.
• Number of forms using Myinfo data.
• Security review, penetration test support and audit logging.
• FAPI 2.0 migration of an older integration.

What security does a Singpass integration need?

Careful key management, strict token validation, secure sessions and full logging. Singpass integration moves sensitive identity data, so the weakest point is usually not the Singpass flow but what happens around it.

• Private signing and decryption keys held in a secrets manager or hardware-backed store, never in code or app bundles.
• A JWKS containing only public signing and encryption keys, provided to Singpass as an object or a public URL.
• Key rotation planned and tested, with overlapping keys so logins keep working.
• Every ID token decrypted and its signature, issuer, audience, nonce and expiry verified.
• Short, server-side sessions with secure, HTTP-only cookies after login.
• Audit logs of logins, Myinfo requests and admin access to identity data.
• Rate limits and monitoring for unusual login patterns.

For larger organisations, we support your security team or an external tester with documentation and fixes. We do not issue security certifications ourselves.

How should Myinfo data be handled under the PDPA?

Collect only approved, necessary items, tell users why, store them securely, keep them only as long as needed, and restrict who can see them. Myinfo data is personal data, and Singapore's Personal Data Protection Act applies to how you use it once it reaches your systems.

NRIC numbers deserve special care. The PDPC's advisory guidelines on NRIC numbers say private organisations should collect them only when required by law or when needed to verify identity to a high degree of accuracy. A Singpass integration often lets you verify identity without storing the full number at all, or store it encrypted with tightly limited access.

We build retention rules into the database, mask identity fields in admin screens by default, and log every view or export. Your privacy notice, written or approved by your counsel, should describe the Singpass and Myinfo data you receive. Our PDPA website guide explains consent, notices and breach readiness in more detail. Compliance remains your company's responsibility, confirmed by your own adviser.

How do you test a Singpass integration before launch?

In Singpass's staging environment first, with test accounts, then with a small controlled rollout in production. For local development, the open-source MockPass project published by Open Government Products on GitHub provides a mock Singpass, Corppass and Myinfo server, which helps developers work without hitting staging constantly.

Our test plan covers the happy path and the ugly ones: a user cancelling at the Singpass screen, an expired request URI, a replayed DPoP proof, a token with the wrong audience, a Myinfo response missing an optional item, a user who already has an email-based account, and a phone switching apps mid-login.

We also test the non-Singpass path, because that is often where real users get stuck. Once staging passes, you submit the production app; after activation, we usually enable Singpass for a share of users or a single form first, watch logs for a few days and then open it fully.

Singpass integration with a remote team in India: who holds what

Your company holds the Singpass application, Corppass roles, production keys and approvals; we hold none of them. That split makes a remote Singpass integration straightforward and keeps control where the regulator and Singpass expect it.

We build against the staging app your team creates, using staging keys. Production keys are generated in your cloud account or secrets manager, and the production client is configured by your team or by us through access you grant and can revoke. India is two and a half hours behind Singapore, so your 10 am call is our 7:30 am, and we stay online through your afternoon for testing sessions.

The first two weeks typically include a scoping call, a written list of Singpass products and Myinfo items with a reason for each, staging app setup by your team, a first working staging login, and a draft user journey document. Quotes are in USD; invoices come from India and are paid by Wise or bank wire. See the guide to hiring Indian developers for how this model works more broadly.

Example: Myinfo auto-fill for a hypothetical tenancy application

Imagine a hypothetical property management company whose rental application form asks tenants to type personal details and upload photos of identity documents, which staff then check by hand. This scenario is illustrative, not a real client.

The Singpass integration would add a “Retrieve Myinfo with Singpass” button at the top of the form. After consent in Singpass, the approved items fill the form; the applicant reviews them, adds the fields Myinfo does not cover, such as preferred move-in date, and submits. Applicants without Singpass would continue with the existing manual path. Identity fields would be masked in the staff portal, and applications would be deleted after a retention period the company's counsel sets.

As part of a custom portal starting from US$900, a build like this might take six to ten weeks, including staging, the user journey document and up to two weeks for production approval. For property sites more generally, see our property agent website guide.

Singpass integration checklist and red flags

Go through this before submitting your production app, whoever builds your Singpass integration.

• Your company, not the developer, owns the Singpass Developer Portal apps and keys.
• Each Myinfo scope has a written reason tied to a form field.
• A non-Singpass path exists and has been tested.
• PAR, PKCE, DPoP and client assertions follow the current Singpass specification.
• ID tokens are decrypted and fully validated before use.
• Mobile apps use Universal Links and App Links, not custom schemes.
• Private keys sit in a secrets manager, with a rotation plan.
• Identity data is masked, logged, encrypted and deleted on schedule.
• The user journey document matches what users actually see.
• Red flag: a developer offering to apply using their own UEN or Corppass.
• Red flag: requesting every available Myinfo item “in case it is useful later”.