Hosted login

The hosted login is the sign-in UI NamoID renders for your end users. You don't build or host it — you redirect users to it and they come back authenticated. It lives on a per-environment subdomain and speaks standard OIDC.

The per-environment subdomain

Each environment is served at its own subdomain:

https://<slug>.id.namoid.in

Everything the user sees — identifier entry, OTP, password, passkey, external-provider buttons, and consent — is rendered there. OIDC discovery, token, userinfo, and JWKS endpoints are scoped to the same issuer. Wildcard TLS is handled for you.

The flow

1. Your app redirects the user to the authorization endpoint (with PKCE).
2. The hosted login presents the sign-in methods you've enabled (see Sign-in methods).
3. The user authenticates and, if required, completes an MFA challenge.
4. The user approves the consent screen (skipped for trusted first-party clients).
5. NamoID redirects back to your redirect_uri with an authorization code.
6. Your app exchanges the code for tokens.

Custom domains

You can serve the hosted login from your own domain — e.g. auth.yourcompany.com — per environment. After you add the domain and prove ownership via DNS, NamoID provisions TLS on demand and serves a discovery document whose issuer is your domain. Pending (unverified) domains don't get a discovery document, so a misconfigured DNS record can't leak an issuer.

Branding and policy

The hosted pages adapt to your environment's configured copy and settings. Sign-in methods, consent links, MFA policy, waitlist state, and signup gating all reflect the selected environment's auth configuration.

Rate limits

The hosted login endpoints are protected with Redis-backed, per-IP and per-target rate limits:

• OTP sends are capped per target and per IP to defend against OTP-flood billing abuse, on top of the per-environment OTP spend cap.
• OTP/password/MFA verification attempts are rate-limited to defend against online brute force.

Limits fail closed for OTP sends — if the rate-limit store is unavailable, sends are blocked rather than allowed unbounded.

End-user self-service

Signed-in users get self-service account pages on the hosted surface:

• Profile — view and edit basic profile fields.
• Passkeys — register and remove passkeys.
• Data export — download a copy of their data (DPDP DSAR) — see Audit & DSAR.
• Delete account — a soft delete that records a tombstone event.

Sign-up gating

Whether new users can register is controlled by the environment's access mode: closed, open, allowlist, or domain allowlist. If waitlist is enabled, new sign-up attempts are queued for manual approval. Approval can notify the user by email when the environment's email delivery is enabled.