Customer identity is the front door to your product. Build login, sign-up, and account security yourself, and you end up maintaining a large, security-sensitive system that has almost nothing to do with the product you set out to ship. CIAM is the category of tools that handles that front door for you. Here's what it is, how it differs from the workforce IAM you may already know, and what an India-first CIAM adds for teams shipping to Indian users.

What is CIAM?

CIAM stands for customer identity and access management. It's the system that signs your customers up, logs them in, secures their accounts, and connects their identity to the rest of your product. Put plainly: it's the authentication and account layer built for the people who use your product, not the employees who work at your company.

A CIAM platform usually owns these jobs:

Registration and login (email, phone, social sign-in, passkeys)
Multi-factor authentication and step-up checks
Session and token management for web, mobile, and API clients
A standards-based way for your apps to ask "who is this user" without each app reinventing it

That last point matters most. A good CIAM speaks open standards. It exposes a single OpenID Connect issuer with discovery and a JWKS endpoint, runs the OAuth 2.1 authorization-code flow, and signs tokens your services can verify on their own. Want the background on those standards? See OAuth 2.1 vs 2.0 and PKCE explained. The OAuth specification and the OpenID Connect spec are the primary sources.

NamoID is built as this kind of CIAM: an environment-scoped OIDC issuer, authorization code with PKCE S256, no implicit or password grant, RS256-signed JWTs, and a JWKS endpoint that exposes the public key.

CIAM vs Workforce IAM

People often conflate CIAM with IAM. They share machinery, but solve different problems for different users. The distinction comes down to who the identities belong to and how they behave.

Dimension	Workforce IAM	CIAM
Who logs in	Employees, contractors	Your customers, end users
Identity count	Hundreds to thousands	Thousands to millions
Who creates accounts	IT provisions them	Users self-register
Primary goal	Access control, least privilege	Smooth sign-up, low drop-off, trust
Typical protocols	SAML, SCIM, LDAP, OIDC	OIDC, OAuth 2.1, passkeys, social login
Scaling pattern	Steady, predictable	Spiky, public internet facing
Data sensitivity	Internal records	Consumer personal data under privacy law

Workforce IAM optimizes for control. An admin decides who gets in and what they can touch. CIAM optimizes for experience and scale. Anyone on the public internet can register, conversion matters, and a clumsy login screen costs you signups. The data differs too. CIAM holds consumer personal data, which in India means it falls squarely under the Digital Personal Data Protection Act. We cover the buying angle in build vs buy auth in India.

The Core Capabilities

A CIAM worth using covers a predictable set of capabilities. Use this as a checklist when you evaluate one.

Authentication methods. Email and password is the floor, not the ceiling. Modern CIAM supports passkeys (WebAuthn), time-based one-time-password (TOTP) MFA, and social federation so users can bring an existing account. The FIDO Alliance maintains the passkey standards. NamoID ships passkeys, TOTP MFA, and Google, GitHub, and LinkedIn federation behind the same issuer. More on passkeys in passkeys and WebAuthn in India.

Token and session security. This is where a lot of homegrown auth quietly breaks. Refresh tokens should rotate, and reusing an old one should revoke the whole chain, which caps the damage from a stolen token. NamoID rotates refresh tokens and revokes the chain on reuse.

Standards and self-verifiable tokens. Your services should be able to verify a token's signature without calling back to the auth server. RS256-signed JWTs plus a JWKS endpoint give you that. PKCE S256 on authorization-code flows closes the code-interception gap.

Multi-tenancy. If you serve multiple tenants, each tenant's users and data must stay isolated. NamoID scopes every request by tenant so one tenant never sees another tenant's data.

Audit and lifecycle. Account creation, login, MFA changes, and provider connections should leave useful evidence. NamoID emits append-only events for security-sensitive lifecycle actions; that does not replace application or infrastructure logs.

Here is what a standards-based discovery handshake looks like against any OIDC issuer:

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

{
  "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"]
}

The code_challenge_methods_supported field listing S256 tells you PKCE is supported. The response_types_supported listing only code tells you there is no implicit grant, which is the OAuth 2.1 default.

Why India Needs India-First CIAM

A generic CIAM gets you OIDC and social login, then usually stops there. Indian products need more, because verifying a real person in India often runs through rails no global vendor ships natively.

You may need to confirm a user holds a verified document, validate user-supplied Aadhaar offline data, or send a one-time code through an India-ready delivery path. A CIAM can coordinate these flows, but each rail still carries its own eligibility, credentials, approval, and data-handling requirements.

The India verification rails that matter:

DigiLocker for fetching government-issued documents with user consent, via the API Setu / DigiLocker APIs. See the DigiLocker integration guide.
Aadhaar offline e-KYC (XML), the offline share flow published by UIDAI. Done right, you store only the last four digits, a name-hash, and the signature-verification result, and you process the full XML in memory without persisting it. See Aadhaar offline e-KYC XML verification.
WhatsApp OTP, Truecaller, and SMS OTP for phone verification. SMS in India must follow the TRAI DLT template registration regime, documented by TRAI. Compare channels in WhatsApp OTP vs SMS OTP.

NamoID has adapters for DigiLocker, Aadhaar offline XML, WhatsApp OTP, Truecaller, SMS OTP, and email OTP, with availability depending on catalog activation, credentials, and provider approval. The current Aadhaar adapter validates and returns parsed data without writing a verification record. Weighing which rail to use? Aadhaar vs DigiLocker vs offline KYC walks through the trade-offs.

DPDP and Residency Inside CIAM

This section is general information, not legal advice.

Your CIAM holds the most sensitive data your product touches: identities, contact details, and verification results. In India that data is governed by the Digital Personal Data Protection Act, 2023, passed by MeitY. The Act and its Rules push you toward three things a CIAM is well placed to provide.

An audit trail. You need to show what happened to personal data and when. An append-only events log gives you that without bolting on a separate system. See DPDP audit trail requirements for engineers.

Data-principal rights. Users can ask for information about processing and request erasure in applicable cases. NamoID's hosted account flow can export processing history and mark an account deleted with a tombstone event. That is identity-layer evidence, not a complete cross-domain rights workflow.

Data residency. You should be able to explain where each category is processed. NamoID's primary production infrastructure runs in AWS Mumbai; optional providers and subprocessors may process data elsewhere. DPDP is not a blanket India-localization rule.

NamoID is built with all three in mind: scoped append-only audit events, processing-history export, account soft deletion with a tombstone event, AES-256-GCM encryption for provider tokens at rest, and primary production infrastructure in AWS Mumbai. Complete cross-domain export and cascading erasure remain broader workflows.

Questions to Ask a CIAM Vendor

Bring this list to any CIAM evaluation.

Do you expose an OIDC issuer with discovery and a JWKS endpoint, and which authorization-code clients require PKCE S256?
Do refresh tokens rotate, and what happens when an old one is reused?
Which authentication methods are built in: passkeys, TOTP, social federation?
Which Indian verification and delivery adapters are production-ready, and which require separate credentials or provider approval?
How is Aadhaar data stored, and is the full number ever persisted?
Which lifecycle actions create append-only events, and exactly what does the privacy export include?
Where are primary data, backups, support access, and optional provider processing located?
Is multi-tenancy isolation enforced at the query level?

If a vendor can't answer the India and DPDP questions cleanly, you'll end up building those parts yourself. For a side-by-side with global incumbents, see the Auth0 alternative for India and the Cognito alternative for data residency.

FAQ

What does CIAM stand for?

CIAM stands for customer identity and access management. It is the system that registers, authenticates, and secures the identities of the people who use your product, as opposed to your employees.

What is the difference between CIAM and IAM?

Workforce IAM manages employee access inside your company and optimizes for control and least privilege. CIAM manages customer identities at internet scale and optimizes for smooth self-service sign-up, security, and privacy compliance. Same standards, different priorities, different data.

Is CIAM the same as single sign-on?

No. Single sign-on is one feature a CIAM can provide. CIAM is the broader product category covering registration, MFA, passkeys, token security, audit logging, and privacy operations.

Why does CIAM India need special features?

Indian products may need local verification or delivery rails such as DigiLocker, Aadhaar offline e-KYC, and DLT-registered SMS. They also need a defensible DPDP operating model. The useful distinction is not “global” versus “Indian”; it is whether the vendor can document the exact adapter readiness, data path, evidence, and responsibility boundaries your use case needs.

Where NamoID fits

NamoID combines an environment issuer for login with selected India-provider adapters, scoped audit events, and transparent residency boundaries. See how the pieces fit in one OIDC issuer for India.

What Is CIAM? Customer Identity for India