MyInfo v5 looks like a version bump. It isn’t. The auth model moved to FAPI 2.0, key management switched from X.509 certificates to JWKS, PKCE and Pushed Authorization Requests are now mandatory, custom-scheme app-launch URIs disappeared, and data retrieval moved to the OIDC userinfo flow. Most teams shipping their first v5 integration hit the same eight pitfalls. This is the field-tested list, with what to do instead.
Who this is for
Engineering teams building or migrating a MyInfo integration in 2026. If you work with a managed integrator under the trusted-aggregator pattern, this is the surface they hold for you — but reading the list is useful for technical due diligence either way. If you’re deciding whether to build in-house or buy, the build-vs-buy comparison in the implementation guide is the better starting point.
1. Treating JWKS as a drop-in for X.509
v3 and v4 apps used X.509 certificate pairs for signing and encryption. v5 uses JSON Web Key Sets (JWKS). You expose a JWKS endpoint with your public keys; GovTech’s portal references that endpoint; your backend signs with the corresponding private key.
What goes wrong: teams treat the migration as a format change and forget that JWKS is a discovery mechanism. The portal expects the live JWKS endpoint to serve the active signing keys, refreshed when keys rotate. If your deployment process rotates keys but doesn’t update the JWKS document, every signed request fails with an opaque PKI signature error. The Singpass token endpoint isn’t broken; your published key set is stale.
Fix: automate JWKS publication off the same process that issues your signing keys. Include both the active and the previous-but-still-valid key in the JWKS for the rotation overlap window. Validate the endpoint on every deploy.
2. Skipping PKCE or PAR
All new MyInfo v5 apps require both:
- PKCE (Proof Key for Code Exchange). Generate a code verifier, derive a code challenge, send the challenge with the authorization request, send the verifier with the token exchange.
- Pushed Authorization Requests (PAR). Push the authorization parameters to GovTech’s PAR endpoint before redirecting the user; you receive a request URI and only that URI goes in the redirect.
What goes wrong: a team familiar with older OAuth flows assembles the authorization parameters as URL query strings and redirects directly. The redirect either fails the app registration validation or — worse — succeeds in staging because the test endpoint accepts it, then breaks in production when FAPI 2.0 enforcement kicks in.
Fix: use a certified OIDC client library that speaks FAPI 2.0 natively rather than rolling the auth flow by hand. The OpenID certified relying-party libraries list shows which libraries are tested for compliance.
3. Holding on to custom-scheme app-launch URIs
v3 / v4 mobile flows commonly used custom-scheme URIs (myapp://callback) for app-launch redirects. v5 dropped this. Mobile apps now use HTTPS app-claimed links — Universal Links on iOS, App Links on Android — with the redirect URL hosted on a domain you control.
What goes wrong: the team registers the new app with a custom-scheme redirect because that worked last time, and the portal validation rejects it, or accepts it but the auth flow fails when the OIDC provider refuses to redirect to a non-HTTPS URI.
Fix: register an HTTPS-only redirect URI tied to a domain you control, then configure the corresponding Universal-Link / App-Link domain association files (apple-app-site-association and assetlinks.json) so the OS routes the deep link to your app.
4. Redirect URI inexact matches
Singpass and MyInfo v5 require redirect URIs to match the registered value exactly — scheme, host, port, path, even the trailing slash. A registered https://app.example.sg/callback will reject https://app.example.sg/callback/ as a different URI.
What goes wrong: the framework you use rewrites URLs (Next.js trailing-slash policy, Express redirect handling, Cloudflare Workers normalization), or your staging and production domains differ in subtle ways, or a CDN strips a path component. The redirect is rejected silently and the auth flow appears to hang.
Fix: register every redirect variant you actually use — staging, production, preview deployments — exactly as your framework emits them. Add an integration test that asserts the served redirect URL byte-for-byte matches the registered value before you trust the deploy.
5. Reusing a multi-purpose v3 / v4 app structure
Older MyInfo apps were sometimes registered with multiple business purposes layered into a single app. v5 expects single-purpose apps — one app per use case, each with its own justified data scope and consent screen.
What goes wrong: a team migrating from v3 / v4 tries to keep the existing multi-mode app structure. The migration application is rejected by GovTech with a request to split the modes. Sometimes this isn’t caught until late in the approval process and the team has to refactor their backend routing under deadline pressure.
Fix: on a v3 / v4 → v5 migration, plan one v5 app per business purpose at the start. If you have a customer signup, an internal staff portal, and a licence-renewal flow, that is three v5 apps in the portal. Each app has its own JWKS, its own client ID, and its own data-scope justification.
6. Calling old data endpoints instead of userinfo
v5 retrieves consented MyInfo data via the OIDC userinfo endpoint, not the older Myinfo data endpoints v3 / v4 exposed.
What goes wrong: a team copies the v4 retrieval code into v5 and calls the wrong endpoint. The error message can be opaque — sometimes 404, sometimes a malformed response — and teams chase phantom auth issues for hours before realising they are calling the wrong URL.
Fix: wire your retrieval to the userinfo_endpoint field returned by Singpass’s OIDC discovery document at /.well-known/openid-configuration rather than hard-coding a URL. Discovery is the contract; URLs change.
7. Treating every 4xx as a provider outage
v5 redirects most authentication errors back to your registered redirect URL with structured error parameters, instead of returning them as token-endpoint failures. Your error handler needs to parse those.
What goes wrong: the team assumes that when the flow fails, Singpass is down. Production tickets escalate to GovTech with subject lines like “Singpass outage in progress”. GovTech replies that the platform is healthy and the actual cause was a missing parameter, an expired key, or a redirect mismatch on the team’s side.
Fix: log the full redirect URL and query parameters on every failed callback. Map known error codes —access_denied, invalid_request, server_error — to user-facing copy that distinguishes “you need to re-consent” from “our integration is misconfigured” from “Singpass is having an issue”. Most production errors fall in the second bucket.
8. Designing the service to depend only on MyInfo
Even when MyInfo is healthy, individual fields can be missing — users with non-standard immigration status, missing housing records, or work-pass holders whose CPF data isn’t available. The pattern of designing a signup form that requires MyInfo data with no manual fallback breaks when fields are unavailable.
What goes wrong: the launch flow assumes every field is always returned. A subset of users — often new PRs, certain work-pass categories, or those with very recent address changes — hit a dead-end signup because their MyInfo response is partial.
Fix: design the signup as MyInfo first, manual fallback for missing fields. Show the user the fields you received, mark fields that came back empty, and let the user type those in. The user experience stays clean, and you stop leaking signups when MyInfo can’t answer.
End-to-end checklist
Before going live with a v5 integration:
- JWKS endpoint serves the active signing key; rotation tested.
- OIDC client library is FAPI 2.0 / PAR / PKCE certified.
- All redirect URIs registered with the exact value your framework emits.
- Apps registered as single-purpose, each with its own data-scope justification.
- Mobile redirects use HTTPS app-claimed Universal Links / App Links, not custom schemes.
- Data retrieval calls
userinfo_endpointfrom OIDC discovery, not a hard-coded URL. - Error handler parses the redirect-back error parameters; distinguishes user, integrator, and platform causes.
- Signup form has a manual-entry fallback for any field MyInfo can return as empty.
- Staging tested with the GovTech test-account set, not just internal mocks.
- Logs include enough context — request ID, redirect URL, parameter set — to diagnose a failure without a redeploy.
When to use a managed integration instead
If your team has shipped a MyInfo v3 or v4 integration before and wants to handle the v5 migration in-house, this list is the map. If your team hasn’t — or your business case doesn’t justify hiring an OIDC-and-FAPI-fluent engineer for a one-time integration — a managed integration under the trusted-aggregator pattern lets you skip the entire surface and pay a per-verification fee instead. The build-vs-buy math, the typical timelines, and the per-vertical cost ranges are covered in the implementation guide.
The short version
MyInfo v5 isn’t a library swap. JWKS replaces X.509, PKCE and PAR are mandatory, custom-scheme URIs are gone, apps must be single-purpose, errors redirect back instead of throwing on the token endpoint, and userinfo is the data endpoint. The eight pitfalls above cover what we see go wrong on first integrations. Avoid them and the production rollout is uneventful; ignore them and you spend two weeks debugging silent “login is broken” reports that turn out to be request-shape issues.
Want to skip this surface entirely? Book a free 20-minute scoping call — we run all of the above on your behalf, end-to-end, under a managed integration. For the broader implementation context see the implementation guide; for the eligibility and personal-vs-corporate distinctions see Corppass vs Singpass and MyInfo Business explained.