DPDP Act 2023India’s data-protection law takes effect 13 May 2027.Read the Act
NamoID
All posts
NamoID Blog

What Is CIAM? Customer Identity for India

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. 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: let's get into it.

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 exactly this kind of CIAM: one OIDC issuer URL, OAuth 2.1 authorization-code flow, PKCE enforced on every flow including first-party clients, RS256-signed JWTs, and a JWKS endpoint that exposes only 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.

DimensionWorkforce IAMCIAM
Who logs inEmployees, contractorsYour customers, end users
Identity countHundreds to thousandsThousands to millions
Who creates accountsIT provisions themUsers self-register
Primary goalAccess control, least privilegeSmooth sign-up, low drop-off, trust
Typical protocolsSAML, SCIM, LDAP, OIDCOIDC, OAuth 2.1, passkeys, social login
Scaling patternSteady, predictableSpiky, public internet facing
Data sensitivityInternal recordsConsumer 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 on every flow closes the authorization-code interception gap.

Multi-tenancy. If you serve multiple organizations, each org's users and data must stay isolated. NamoID scopes tenants by an org identifier so one org never sees another's data.

Audit and lifecycle. Account creation, login, MFA changes, and provider connections should all leave a trail. NamoID is built around an append-only events table where every state change appends an event.

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, check a name against an Aadhaar record without storing the full number, or send a one-time code over a channel users actually trust. India-first CIAM puts those rails behind the same issuer URL you already use for login, so you're not stitching together five vendors.

The India verification rails that matter:

NamoID puts DigiLocker, Aadhaar offline-XML, WhatsApp OTP, Truecaller, DLT-compliant SMS OTP, and email OTP behind the same OIDC issuer as login. Aadhaar data is masked by design: only the last four digits, a name-hash, and the verification result are stored, and the full XML is never persisted. Weighing which rail to use? Aadhaar vs DigiLocker vs offline KYC walks through the trade-offs, and the single OIDC issuer model explains why one issuer beats a pile of point integrations.

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 draft 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 subject rights. Users can ask for their data and ask for deletion. A CIAM that exposes a DSAR export of a user's event history and connected providers, and that cascades a soft-delete plus a tombstone event on deletion, makes those requests routine instead of a fire drill.

Data residency. The draft rules around localization mean you should be able to say where Indian users' data lives. NamoID is built with a per-organization residency hint, aimed at keeping India data in India. We cover this in data localization under DPDP Rule 15 and lay out the wider obligations in the DPDP compliance checklist for SaaS.

NamoID is built with all three in mind: an append-only events table, a DSAR export endpoint, deletion that cascades a soft-delete plus tombstone, AES-256-GCM encryption for provider tokens at rest, and a residency hint per organization.

Questions to Ask a CIAM Vendor

Bring this list to any CIAM evaluation.

  1. Do you expose a single OIDC issuer with discovery and a JWKS endpoint, and do you run OAuth 2.1 with PKCE on every flow?
  2. Do refresh tokens rotate, and what happens when an old one is reused?
  3. Which authentication methods are built in: passkeys, TOTP, social federation?
  4. Do you support Indian verification rails (DigiLocker, Aadhaar offline-XML, WhatsApp and SMS OTP) behind the same issuer?
  5. How is Aadhaar data stored, and is the full number ever persisted?
  6. Is there an append-only audit log and a DSAR export for DPDP?
  7. Can data residency be set per organization?
  8. 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 platform that also covers registration, MFA, passkeys, token security, audit logging, and, for India, verification rails and DPDP support.

Why does CIAM India need special features?

Indian products often must verify users through local rails like DigiLocker, Aadhaar offline e-KYC, and DLT-compliant SMS, and they must meet DPDP obligations such as audit trails, data subject rights, and data residency. A global CIAM rarely ships these, so an India-first CIAM closes the gap.

See a Demo

NamoID is built to be the one issuer URL behind login, India verification rails, and DPDP-ready audit and residency. The product ships soon. Want to see how it fits your stack? Book a 30-minute walkthrough at calendly.com/polymindslabs/30min or reach us at hello@namoid.in.