One OIDC Issuer for Auth, India KYC, and DPDP

Your identity stack rarely starts as one thing. You bolt an auth vendor onto a KYC vendor onto an OTP carrier onto a hand-rolled audit log, and every seam becomes a place where tokens, user records, and consent receipts quietly drift out of sync. There's a cleaner shape. Put one OIDC issuer URL in front of login, social sign-in, India's verification rails, and a DPDP-grade audit trail, all behind the same standards-based contract. That's the argument this post makes, including where it doesn't hold.

NamoID is built to be that issuer. It is pre-launch, so everything below describes how the product is designed, not a shipped feature list you can buy today.

The multi-vendor stitching problem

A typical India-first stack looks like this once it is in production:

• An authentication provider for email and social login.
• A separate KYC or verification vendor for DigiLocker and Aadhaar.
• An SMS aggregator for OTP, with its own DLT template registration.
• A WhatsApp Business partner for OTP delivery.
• A custom audit log, because no single tool above produces something a regulator can read end to end.

Each box is a contract, an SLA, a data-sharing agreement, and a failure mode. More importantly, each box owns a different fragment of the same user. Your auth vendor knows the session. Your KYC vendor knows the verification result. Your SMS aggregator knows the phone number. When a user files a data-access or deletion request under the Digital Personal Data Protection Act, you have to fan out across all of them and reassemble a coherent record by hand.

That stitching is where compliance risk hides. The user identifier in your auth system may not match the one in your KYC vendor. Consent captured at the OTP step may never reach the audit log. Provider tokens may sit unencrypted in a vendor you never reviewed. None of these are exotic bugs. They are the predictable result of asking four systems to agree on one identity with no shared contract. If you are weighing this against rolling your own, our build vs buy auth in India walkthrough covers the hidden costs on both sides.

What a single issuer URL gives you

OpenID Connect already defines the shared contract you need. An OIDC issuer publishes a discovery document at a well-known path, and that document points to every endpoint a relying party uses: authorization, token, userinfo, and the JWKS key set. The spec for this is OpenID Connect Discovery, and the token rules sit on top of the OAuth 2.1 draft.

Collapse authentication and KYC behind one issuer URL and three things become true at once:

1. Your application integrates against one standard, not four proprietary APIs. You configure an issuer, run discovery, and validate ID tokens against the published JWKS. That is the same code you would write for any compliant OIDC provider.
2. Every rail shares one user record and one session model. Whether a user logged in with a passkey, a Google account, or a DigiLocker check, they resolve to the same subject identifier behind the issuer.
3. Consent and verification events land in one place, in order, because they all flow through the same service.

NamoID is built around exactly this shape. One issuer URL exposes OIDC discovery and JWKS, runs the OAuth 2.1 authorization-code flow, and enforces PKCE on every flow, including first-party clients. There is no implicit grant. Refresh tokens rotate on every use, and reusing an old refresh token revokes the entire chain, which is the replay defense OAuth 2.1 expects. ID tokens and access tokens are RS256-signed, and only the public key is ever exposed through JWKS. If the standards changes are new to you, OAuth 2.1 vs 2.0 and PKCE explained cover the why behind those rules.

So you don't have to choose between standards and local rails. You get both behind the same contract.

Verification rails as auth factors

The reason most teams end up stitching is that India verification does not live in the auth box. DigiLocker, Aadhaar, WhatsApp OTP, and Truecaller are each their own integration with their own SDK, callback, and signature format. Treating them as separate from login is what forces the four-vendor sprawl.

The cleaner model is to treat verification rails as factors behind the same issuer, so that "verify this user" and "authenticate this user" run through one flow. NamoID is built to combine authentication and KYC this way. Behind the single issuer you have:

• Passkeys (WebAuthn) and TOTP MFA for phishing-resistant and second-factor auth. WebAuthn is a FIDO Alliance and W3C standard; see passkeys and WebAuthn in India for the local rollout picture.
• Social federation with Google, GitHub, and LinkedIn.
• DigiLocker for issuing-authority document checks, built on the government API Setu DigiLocker APIs. Our DigiLocker API integration guide walks the consent and pull flow.
• Aadhaar offline e-KYC via the share-code-protected XML that UIDAI publishes, with signature verification on the document.
• WhatsApp OTP and SMS OTP on a DLT-compliant template path, per the TRAI commercial communication regulations.
• Email OTP as a fallback factor.

A short comparison of what these rails are good for:

Aadhaar handling deserves a specific note. NamoID is built to store only the last four digits, a name-hash, and the signature-verification result. The full offline XML is processed in memory and never persisted. That is a deliberate data-minimisation choice, and the trade-offs against full DigiLocker pulls are covered in Aadhaar vs DigiLocker vs offline KYC.

A DPDP audit trail for free

Once every login and verification event flows through one issuer, the audit trail stops being a separate project. It becomes a byproduct.

NamoID is built around an append-only events table. Every state change appends an event: a registration, a login, an MFA enrolment, a provider connection, a consent grant, a token issuance, a deletion. Because the events are immutable and ordered, you get a record a regulator can read without you reconstructing it across vendors.

This maps directly onto what the DPDP Act and its rules expect from a Data Fiduciary. A DSAR export endpoint is built to return a user's full event history plus their connected providers, which supports the access right. Deletion is built to cascade a soft-delete and write a tombstone event, so erasure is itself auditable. Provider access and refresh tokens are encrypted at rest with AES-256-GCM, and each organisation carries a data-residency hint so India data can be kept in India, which speaks to data localization under DPDP Rule 15.

If you are mapping these obligations for your own service, start with the DPDP compliance checklist for SaaS and the engineer-focused DPDP audit trail requirements. For the roles themselves, data fiduciary vs data processor clarifies who owns which duty. This section is general information, not legal advice; confirm your obligations with counsel against the official DPDP Act text from MeitY.

OIDC discovery and integration

Because the issuer is a standard OIDC provider, integration is the same discovery-then-validate pattern you already know. You fetch the discovery document, read the endpoints and JWKS URI from it, then validate tokens against the published keys.

Fetching discovery from any compliant issuer looks like this:

curl https://issuer.example.com/.well-known/openid-configuration

The response advertises the endpoints and supported features:

{
  "issuer": "https://issuer.example.com",
  "authorization_endpoint": "https://issuer.example.com/authorize",
  "token_endpoint": "https://issuer.example.com/token",
  "jwks_uri": "https://issuer.example.com/jwks.json",
  "response_types_supported": ["code"],
  "code_challenge_methods_supported": ["S256"],
  "id_token_signing_alg_values_supported": ["RS256"]
}

Note code as the only response type and S256 as the PKCE method. That is the OAuth 2.1 posture: authorization-code with PKCE, no implicit grant.

On the client, you validate the ID token against the JWKS using a standard library. With a generic OIDC client, that is roughly:

import * as client from "openid-client";
 
const config = await client.discovery(
  new URL("https://issuer.example.com/.well-known/openid-configuration"),
  process.env.CLIENT_ID!,
);
 
// The library reads jwks_uri from discovery and validates
// the RS256 signature for you during the code exchange.
const tokens = await client.authorizationCodeGrant(config, currentUrl, {
  pkceCodeVerifier: verifier,
  expectedState: state,
});

The point is that nothing here is NamoID-specific. Any team that has integrated a compliant OIDC provider can point the same code at this issuer. The India rails sit behind the authorization endpoint as factors, so they do not change your client code.

What the architecture looks like

Underneath, the design follows a stateless-service model so it can run as identical containers behind a load balancer.

• The issuer service terminates OIDC and OAuth 2.1, enforces PKCE, signs tokens with RS256, and publishes JWKS.
• Verification rails (DigiLocker, Aadhaar offline XML, WhatsApp, SMS, Truecaller, email) are pluggable providers behind that service, each emitting events.
• Postgres holds the durable state: users, sessions, the append-only events table, and encrypted provider tokens. Redis holds session cache and rate-limit counters.
• Multi-tenancy is scoped by organisation, so a user in one org never resolves against another org's data, and each org carries its residency hint.

The flow for a verified login reads top to bottom: your app redirects to the authorization endpoint with PKCE, the user completes a factor (a passkey, or a DigiLocker check, or an OTP), the service writes the consent and verification events, exchanges the code for rotating tokens, and returns an RS256 ID token your app validates against JWKS. One round trip through one issuer produces both the session and the audit record.

If you're migrating off something today, the Auth0 alternative for India and Cognito alternative with data residency comparisons pick up where this leaves off.

FAQ

What is a single OIDC issuer?

It is one OpenID Connect provider, reachable at a single issuer URL, that publishes a discovery document and JWKS and handles your authorization-code flow. Relying parties integrate against that one URL instead of separate auth, KYC, and OTP vendors.

Can one issuer handle both authentication and KYC?

Yes, when verification rails are modelled as factors behind the issuer. NamoID is built to combine authentication and KYC so that DigiLocker, Aadhaar offline XML, and OTP checks run through the same flow that issues your tokens, and all of them emit audit events.

How does a single issuer help with DPDP compliance?

Because every login and verification event flows through one service, the append-only events table becomes a regulator-readable audit trail, and a DSAR export can return one user's full history plus connected providers. This is general information, not legal advice.

Is NamoID available now?

Not yet. NamoID is pre-launch and in soft launch. Everything described here is how the product is built, and you can book a demo to see the design and timeline.

See it for yourself

If you are trying to collapse login, India verification, and a DPDP audit trail into one issuer, we would like to show you the design. Book a demo at calendly.com/polymindslabs/30min, or write to us at hello@namoid.in. No sign-up yet, the product is not live, but we are happy to walk you through it.