Customer authentication, ready to ship.
Scoped access when AI clients arrive.
Launch branded customer sign-in with Hosted Auth. When an AI client needs access, let the user approve one resource and explicit actions instead of sharing their application session. Primary infrastructure runs in AWS Mumbai, with documented provider and subprocessor boundaries and DPDP-readiness controls.
No payment card during public beta · Customer Identity available now · MCP Authorization in developer preview
Built on the standards every serious stack runs on
- OpenID ConnectDiscovery
- OAuthPKCE authorization
- WebAuthnPasskeys
- FIDO2Strong auth
- JWT · RS256Signed tokens
Identity methods
Available
- GitHub
Planned or selected rollout
- SMS
Launch Hosted Auth in three steps.
Create a Test application, register its exact callback URL, and start Hosted Auth with its Client ID. The SDK handles Authorization Code + PKCE for you; browser applications never need a client secret.
- 1
Register your Test application
Enable the sign-in methods you need and register the exact callback URL for your application.
GET /.well-known/openid-configuration - 2
Start Hosted Auth
Call the SDK sign-in helper. It creates state and PKCE, then sends the browser to your branded hosted sign-in page.
GET /oauth/authorize - 3
Complete the callback
Let the SDK validate the response, exchange the one-time code, and establish your application session.
POST /v1/oauth/token
Authenticate the person. Authorize the AI client separately. Keep one operating model.
Customer Identity handles sign-in and user sessions. MCP Authorization gives an AI client its own resource, scopes, audience, expiry, and revocation boundary. Future Workforce Identity and Agent Access work is labelled separately below.
Customer Identity · available in public beta
Hosted sign-in, social providers, passkeys, MFA, users, sessions, and audit for customer-facing applications.
Hosted login
A polished login on your own domain, without building authentication UI.
Integrate with standard OIDC
Use discovery and SDK helpers while NamoID securely hosts credential collection.
Passkeys & MFA
Offer phishing-resistant passkeys and add TOTP as a second factor.
Social login
Let people in with accounts they already have.
Workforce Identity · in design
A design-partner direction for employee lifecycle, assignments, and standards-based SSO—not a product you can deploy today.
MCP Authorization · developer preview
Let a user approve one resource and explicit actions, then give the AI client a short-lived token for that audience.
Agent Access · in design
A design-partner direction for governed connections to external providers without exposing credentials to agent code.
Test & Live environments
Keep experiments, credentials, users, and production policy inside explicit environment boundaries.
Audit & privacy
Scoped append-only security events and user-run processing-history exports.
Use the OIDC library your stack already runs.
Read discovery from the environment issuer, validate signed tokens with its public JWKS, and keep token verification in your application. NamoID packages can shorten integration work, but the protocol surface remains standard OAuth and OpenID Connect.
Works with standards-compliant OIDC libraries. Read the docs or open the API reference. Book a demo →
# Prefer OIDC? Use the environment issuer with any OIDC library$ curl https://acme-game-7f3a1c.sandbox.namoid.in/.well-known/openid-configuration { "issuer": "https://acme-game-7f3a1c.sandbox.namoid.in", "authorization_endpoint": "https://acme-game-7f3a1c.sandbox.namoid.in/oauth/authorize", "token_endpoint": "https://acme-game-7f3a1c.sandbox.namoid.in/v1/oauth/token", "jwks_uri": "https://acme-game-7f3a1c.sandbox.namoid.in/v1/oauth/jwks.json"}
Security claims you can inspect.
Identity is only worth what it protects. These aren’t roadmap promises. They’re how the service is built today.
Identity data is minimized
Security and audit flows prefer scoped identifiers over names, emails, credentials, or other personal data when the identifier is enough.
Encrypted at rest
Provider access and refresh tokens are sealed with AES-256-GCM, and never written to logs.
Asymmetric signing
Tokens are signed RS256. Only the public key is published via JWKS; the private key never leaves the service.
PKCE S256 for authorization code
Required for authorization-code clients, including first-party clients. There is no implicit or password grant.
Refresh token rotation
Every refresh issues a new token and revokes the old one. A replayed token kills the entire chain.
Append-only audit
Security-sensitive state changes produce scoped audit evidence rather than overwriting the history that investigators need.
- PKCE enforced
- RS256 · JWKS
- AES-256-GCM at rest
- DPDP-readiness controls
- GDPR-informed privacy controls
- ISO 27001 · SOC 2 readiness
Primary identity workloads run in Mumbai. Boundaries included.
- Primary identity workloads in AWS Mumbai
- DPDP-readiness workflows and documented boundaries
- Subprocessors and transfer boundaries disclosed
Compliance should be something your team can operate.
India’s final DPDP framework is notified, with major substantive obligations phasing in by May 2027. That turns notice, consent, rights handling, security, and incident readiness into product work. You remain the Data Fiduciary; NamoID supplies identity controls and evidence that can support those responsibilities.
Delegated authorization becomes inspectable
MCP resource grants preserve the resource and scopes a user approved, so delegated access can be inspected and revoked independently.
People can correct their profile
Hosted account flows support profile correction, processing-history export, and an account soft-deletion request without inventing a separate support workflow.
Security events keep their history
Security-sensitive lifecycle actions produce append-only audit events with tenant, project, and environment context.
Primary infrastructure in Mumbai
Primary production infrastructure runs in AWS Mumbai. Optional providers and subprocessors may process data elsewhere, and those boundaries are documented.
DPDP compliance still depends on your notices, purposes, policies, and operations. NamoID supplies the identity controls and evidence rather than a legal certificate.
The things teams ask before they switch.
What can we use today?
Customer Identity is available under public-beta terms. MCP Authorization is a developer preview. Workforce Identity and Agent Access are design-partner product directions, not generally available features.
Is NamoID only for companies in India?
No. Customer Identity uses OAuth, OpenID Connect, PKCE, WebAuthn, JWT, and JWKS. India is where the product has additional depth: DPDP-focused workflows, local operating context, and India deployment requirements. SAML belongs to the Workforce Identity direction, which is not generally available yet.
Does NamoID guarantee DPDP compliance?
No product can make an organization compliant on its own. NamoID provides identity controls and evidence for consent, audit, privacy operations, minimization, and retention. Your organization remains responsible for its notices, purposes, policies, and legal obligations.
Do you have ISO 27001 or SOC 2 certification?
Not today. ISO 27001 and SOC 2 inform our control-readiness program, but NamoID does not currently claim ISO 27001 certification or a SOC 2 report. Completed assessments are listed on the Security page.
Can we migrate from another identity provider?
Usually, but the work is broader than changing an issuer. Callback and token-validation configuration can often move cleanly through OAuth and OpenID Connect; users, password hashes, linked identities, claims, and existing sessions need an explicit migration plan before production cutover.
Do we have to use Hosted Auth?
Hosted Auth through redirect or popup is the supported production path today. SDKs handle the OAuth and OpenID Connect mechanics, while NamoID hosts credential collection, passkeys, social sign-in, and MFA. A general native authentication API is not currently offered for production use.
How do MCP Authorization and Agent Access differ?
MCP Authorization protects a resource your product exposes to AI clients. Agent Access is the planned inverse: allowing a named agent to use a human-authorized external account through short-lived, policy-bound access without receiving the provider credential.
Run your first customer sign-in in Test. Keep AI access separate.
Configure a callback and complete Hosted Auth first. If your product exposes an MCP server, talk with us about resource, scope, audience, consent, and expiry boundaries.
Customer Identity public beta · MCP Authorization developer preview · Workforce Identity and Agent Access in design.