Introduction

NamoID is a hosted identity service that gives your app a single OpenID Connect issuer URL with hosted sign-up, sign-in, consent, and token issuance behind it. Email OTP, passwords, passkeys, multi-factor authentication, and configured external identity providers all end in the same standards-compliant OAuth/OIDC flow. You point any conformant OIDC client library at the issuer's discovery document instead of building and operating the identity surface yourself.

What you get

• One discovery URL per environment, with full OpenID Connect compliance — authorization-code flow with mandatory PKCE, refresh-token rotation, and overlapping JWKS rotation so verifiers never see a hard cutover.
• Hosted login at <your-slug>.id.namoid.in (or your own custom domain), so you never build another sign-in form. Email OTP, password, passkey, and enabled external-provider buttons are rendered from your environment config.
• A DPDP-aligned audit trail. Consent moments, sign-ins, account changes, key changes, and webhook events land in an append-only event store, and end users can self-serve a data export.
• Multi-tenant by default. Tenants own projects; projects split into test and live environments so staging never collides with production.

What you don't have to build

• A credential store, password hashing, or session management
• Hosted email OTP delivery and verification-code handling
• OAuth 2.1 / OIDC endpoints, PKCE, refresh rotation, or JWKS key rotation
• Consent capture and an audit-ready event log

How it fits together

Tenant
├── Platform keys      (namoid_platform_sk_…; automation / AI setup)
└── Project  ──────────────► one OIDC issuer per environment
    ├── Environment: test   ──► <slug>…-test.id.namoid.in
    └── Environment: live   ──► <slug>.id.namoid.in
        ├── Applications     (OAuth/OIDC clients: idpc_live_… / idps_live_…)
        ├── Auth keys        (namoid_auth_pk_live_… / namoid_auth_sk_live_…)
        ├── Webhooks         (signed event delivery)
        └── End Users        (everyone who consented to a client)

Your application is an OAuth client inside an environment. It sends users to the hosted login, receives them back with an authorization code, and exchanges that code for ID and access tokens. See Multi-tenancy for the full hierarchy.

Where to next

• Just want it working? Start with Getting started for an end-to-end integration, or jump to the Next.js quickstart.
• Using another framework? Any OIDC library works — see Other OIDC clients.
• Want the mental model? Read OAuth 2.1 + OIDC and Tokens & claims.
• Issuing server-side credentials? See API keys and Webhooks.