Getting started

This walkthrough takes you from zero to a running OIDC sign-in flow against a project you own. You'll need a NamoID account (sign up at console.namoid.in) and a callback URL on your app.

If you're on Next.js, the Next.js quickstart is the fastest path. This page is the framework-agnostic version.

1. Create your tenant

Your first dashboard sign-in opens the onboarding flow. Pick a tenant name. The tenant owns your team, projects, platform keys, and invitations.

2. Create a project

Every NamoID resource lives under a project. From the sidebar pick Projects → New project. A project starts with isolated test and live environments. Environments are fully isolated — separate users, credentials, and OTP budgets. See Environments.

3. Pick the environment you're building against

Use the environment switcher in the project header to select test while you integrate. Credentials minted in test carry a test segment (idpc_test_…) and only work against the test issuer, so test sign-ups never pollute your production user count.

4. Create your first application

From the selected environment's Applications tab, choose New application and provide:

A display name (shown on the consent screen)
One or more redirect URIs, e.g. https://your-app.example/auth/callback
A client type — confidential for server-rendered apps (gets a secret), public for SPAs/mobile (PKCE only, no secret)

NamoID issues a client_id (idpc_test_…) and, for confidential applications, a client_secret (idps_test_…). The secret is shown exactly once at creation — copy it now. You can rotate it later from the same tab.

Note: PKCE is required on every flow, including confidential clients. Any conformant OIDC library enables it automatically. There is no implicit flow and no password grant — see OAuth 2.1 + OIDC.

5. Grab your issuer URL

The environment's OIDC issuer URL is shown at the top of the Applications tab. It looks like https://<slug>.id.namoid.in (production) or a test variant. The discovery document lives at:

https://<slug>.id.namoid.in/.well-known/openid-configuration

Everything your client needs — authorization, token, userinfo, and JWKS endpoints — is discovered from that one URL. You never hardcode endpoint paths.

6. Point your OIDC client at the issuer

Any standards-compliant library works. With Auth.js (NextAuth v5):

// auth.ts
import NextAuth from "next-auth";

export const { handlers, signIn, signOut, auth } = NextAuth({
  providers: [
    {
      id: "namoid",
      name: "NamoID",
      type: "oidc",
      issuer: process.env.NAMOID_ISSUER, // https://<slug>.id.namoid.in
      clientId: process.env.NAMOID_CLIENT_ID,
      clientSecret: process.env.NAMOID_CLIENT_SECRET,
      authorization: { params: { scope: "openid profile email" } },
    },
  ],
});

Set the environment variables:

NAMOID_ISSUER=https://<slug>.id.namoid.in
NAMOID_CLIENT_ID=idpc_test_…
NAMOID_CLIENT_SECRET=idps_test_…

Hit your app's sign-in route. You should land on the NamoID hosted login, authenticate with one of the methods enabled for the environment, approve the consent screen when required, and return to your callback with an authorization code. Your OIDC client exchanges the code at the discovered token endpoint and receives an ID token + access token. Decode the ID token and you'll see the standard claims — sub, email, email_verified, and more (see Tokens & claims).

8. Confirm the user appears

Back in the dashboard, open the selected environment's Users tab. The account you just authenticated with shows up with its verified state, first/last sign-in, and the clients it has consented to.

Next steps

Choose sign-in methods in the selected environment's Authentication tab — overview
Turn on MFA or passkeys
Subscribe to user lifecycle webhooks
Promote test config to live and ship — see Environments