One OIDC Issuer for Auth, India KYC, and DPDP

Your identity stack rarely starts as one thing. You bolt an auth vendor onto a verification provider, an OTP carrier, and a hand-rolled audit log. Every seam becomes a place where tokens, user records, and evidence drift out of sync. An environment-scoped OIDC issuer gives authentication a stable standards-based contract, while selected provider adapters and scoped audit events can reduce the surrounding integration work. This post explains that shape—and where the single-issuer promise stops.

NamoID Customer Identity is available under early-access terms. The India verification rails discussed below have separate activation, credentials, approval, and production-readiness requirements.

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 this shape. One environment issuer exposes OIDC discovery and JWKS, runs authorization code with PKCE S256, and offers no implicit or password grant. Refresh tokens rotate, replay revokes the chain, and tokens are RS256-signed. This is an OAuth 2.1-aligned security profile; OAuth 2.1 itself remains an active IETF draft.

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's current offline-XML adapter validates signed input and returns parsed data without writing a verification record. Production response handling, logs, and retention must still be reviewed end to end, and this is not a claim of UIDAI approval.

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 emits append-only events for security-sensitive lifecycle actions with tenant, project, and environment context where applicable. It does not claim that every write path or every external system is covered, so customers still need application and infrastructure evidence.

These controls can support a Data Fiduciary's DPDP operating model, but the boundary matters. The hosted account flow can export processing history and mark an account deleted with a tombstone event. It does not yet provide a complete connected-provider export or automated erasure across customer systems. Provider tokens are encrypted at rest with AES-256-GCM. Primary production infrastructure runs in AWS Mumbai, while optional providers and subprocessors may process data elsewhere.

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 behind the issuer. NamoID has adapters for DigiLocker, Aadhaar offline XML, and OTP channels, but provider availability, approval, persistence, and audit coverage vary by flow.

How does a single issuer help with DPDP compliance?

An environment issuer can centralise useful identity evidence, but it does not automatically observe every application or external-provider action. NamoID records append-only events for security-sensitive lifecycle actions and exposes processing-history export; customers still need application, infrastructure, notice, and erasure evidence. This is general information, not legal advice.

Is NamoID available now?

Customer Identity is available under early-access terms. Provider-specific verification capabilities have separate activation, credentials, approval, and readiness requirements. Confirm the integration you need before planning a production migration.

See it for yourself

If you are trying to collapse login, India verification, and a DPDP audit trail into one identity layer, sign up or write to us at hello@namoid.in.