How to integrate Singpass for your business

What Singpass integration actually means

Singpass integration connects your application to Singapore's National Digital Identity (NDI) infrastructure. Your users log in with the same credentials they use for government services, and you get government-verified identity data back.

Technically, Singpass runs on OpenID Connect (OIDC). But it's not standard OAuth 2.0. GovTech requires the FAPI 2.0 Security Profile on top of OIDC, adding cryptographic protections that standard OAuth doesn't ask for. Most OAuth libraries won't work out of the box with Singpass. That's the part that catches teams off guard.

For businesses, the result is straightforward: instead of asking visitors to type their NRIC, fill out a form, or flash a physical ID, they scan a QR code or tap a button in the Singpass app. Your system gets their verified name, NRIC (store it masked, not in full), and whatever MyInfo fields you've requested.

Why businesses need Singpass

Two things are pushing Singapore businesses toward Singpass: regulation and operational reality.

The PDPC NRIC rules

Two PDPC rules are closing in on the NRIC logbook. Since 1 September 2019, the NRIC Advisory Guidelines have told organisations not to collect full NRIC numbers or keep copies of the physical card by default, unless the law requires it or they genuinely need it to establish identity to a high degree of fidelity. Separately, a June 2025 PDPC and CSA joint advisory requires organisations to stop using NRIC numbers to authenticate people by 31 December 2026, with enforcement stepping up from 1 January 2027. If you still ask visitors to write down their NRIC at a reception desk or guard house, you'll need an alternative. Singpass-powered verification is the cleanest one: the government confirms the visitor's identity, and you never store their full NRIC.

The operational case

Beyond compliance, there are practical reasons too:

• Self-reported info is unreliable. Visitors give fake names, wrong NRICs, or just skip the form. Singpass confirms identity at the source.
• Paper logbooks are slow. A Singpass QR scan takes three seconds. No handwriting to decipher, no forms to file, no data entry mistakes.
• 4 million people in Singapore already have Singpass. They know it from SafeEntry during COVID and from government e-services. There's no adoption curve.
• MyInfo auto-fill cuts friction from onboarding. Instead of asking customers to type their address or employment details, you pull verified data with their consent.

The technical requirements

If you're thinking about building Singpass integration in-house, here's what you're signing up for. The stack has three layers. Each one adds requirements.

Layer 1: OIDC (OpenID Connect)

This is the base authentication protocol. Singpass exposes standard OIDC endpoints: /authorize, /token, and /userinfo. You handle discovery via /.well-known/openid-configuration, validate ID tokens, verify nonces, and pull signing keys from the JWKS endpoint.

Layer 2: FAPI 2.0 Security Profile

This is where most of the complexity lives. FAPI 2.0 is a financial-grade security layer, and GovTech requires it for all Singpass relying parties. It adds four requirements on top of standard OIDC:

Requirement	What it does	Specification
Pushed Authorization Requests (PAR)	Auth parameters are POSTed to the server first, not sent in the browser URL. Prevents request tampering.	RFC 9126
PKCE with S256	Proof Key for Code Exchange prevents authorization code interception. Only S256 hash method is accepted.	RFC 7636
DPoP tokens	Demonstration of Proof-of-Possession binds each access token to a specific cryptographic key. Stolen tokens are useless without the key.	RFC 9449
JWKS key management	You host your public keys at a /.well-known/jwks.json endpoint. Keys must be rotated regularly.	RFC 7517

Standard OAuth libraries handle OIDC and PKCE, but not PAR or DPoP. You'll probably need to write the FAPI 2.0 layer yourself or find a library that specifically supports it.

Layer 3: NDI (National Digital Identity)

NDI is the government framework Singpass sits inside. This layer is mostly paperwork: you apply to GovTech as a relying party, pass their security assessment, test in the staging sandbox, and get production approval. Expect 4 to 8 weeks after your code is ready.

Build vs buy: the honest comparison

This is the decision most businesses are actually trying to make. Here's how the two paths compare.

	Build it yourself	Use a registered provider
Timeline	3 to 6 months (implementation + GovTech onboarding)	Hours to days
Engineering cost	Several months of senior backend engineering time	Free tier available, then usage-based pricing
GovTech registration	Required. You handle the application and security assessment.	Not required. You operate under the provider's registration.
FAPI 2.0 code	You implement and maintain PAR, DPoP, PKCE S256, JWKS.	Handled by the provider.
Ongoing maintenance	Key rotation, cert renewal, spec updates from GovTech.	Handled by the provider.
Control	Full control over the auth flow and data handling.	Provider's API/webhooks. Good enough for most use cases.
Best for	Teams with specific requirements that providers can't meet.	Most businesses that need Singpass auth without building infra.

For most businesses, buying wins. Building a FAPI 2.0 integration is real engineering work, and keeping it running is an ongoing commitment. The build path only makes sense if you have specific needs around data handling, auth flow customisation, or regulatory constraints that a provider can't cover.

MyInfo for business: what you can access

MyInfo is a separate service in the NDI ecosystem. It lets you pull government-verified personal data with user consent. It's closely tied to Singpass but has its own API onboarding process.

What data is available

Singpass Login gives you the basics: NRIC/FIN, name, date of birth, mobile number, and email. Those map to the openid, uinfin, name, dob, mobileno, and email scopes.

MyInfo goes deeper:

• Residential and registered address
• Employment details (employer, occupation, income)
• Education qualifications
• CPF contributions and balances
• Vehicle ownership
• HDB ownership details

Every additional field needs explicit user consent during the auth flow. Users see exactly what you're requesting and can accept or decline.

MyInfo Business

MyInfo Business is the B2B variant. It gives you corporate entity data: UEN, company name, registration date, entity type, registered address, and the list of appointed officers. Useful when you're onboarding business customers and need to verify the company, not just the person.

GovTech onboarding: what to expect

If you're building a direct integration (not using a provider), you'll go through GovTech's relying party onboarding. Here's what the timeline actually looks like.

Months 1 to 2: implementation

Write the FAPI 2.0 integration: PAR endpoint, DPoP proof generation, PKCE S256 flow, JWKS key management, and the full OIDC token exchange. Test against GovTech's staging sandbox at stg-id.singpass.gov.sg. Expect edge cases around token binding and key rotation that aren't well-documented.

Months 2 to 3: staging testing

Run your integration against staging with test accounts. GovTech provides test NRICs and sandbox credentials. This phase usually surfaces issues with DPoP proof formatting, clock skew tolerance, and JWKS caching.

Months 3 to 4: security assessment

Submit your relying party application to GovTech. They'll review your implementation, security posture, and data handling. This takes 4 to 8 weeks. If they find issues, you fix them and resubmit.

Months 4 to 6: production approval and go-live

Once approved, you get production credentials and switch from staging to production endpoints. Plan for a period of parallel testing before going fully live.

A registered provider like SingVMS eliminates this entire timeline. Our registration, security assessment, and production approval are already done. You sign up, configure, and go live.

Getting started with SingVMS

SingVMS is a Registered Singpass Provider. We handle the full FAPI 2.0 authentication flow so you don't have to register with GovTech, build FAPI 2.0, or manage cryptographic keys.

Two ways to use SingVMS:

1. Hosted check-in flow (no code)

Sign up at app.singvms.sg, grab a QR code for your location, and print it. Visitors scan, authenticate with Singpass, and you see the check-in on your dashboard with verified identity data. That's it. This is how most visitor management setups work: offices, guard houses, condos, events.

2. REST API (for developers)

For teams that want Singpass authentication inside their own app, SingVMS has a REST API with webhook callbacks. You trigger an auth session via API, the user authenticates with Singpass, and you get verified identity data through a webhook. Standard REST patterns. No proprietary SDK.

Both paths include:

• Government-verified identity (masked NRIC, name, and consented MyInfo fields)
• No FAPI 2.0 code on your side
• No GovTech relying party registration needed
• Free plan: 50 check-ins per month, no credit card required
• PDPA compliant by design (no full NRIC storage)