Auth.js — formerly NextAuth — is a relying-party library you host inside your Next.js app. NamoID is a managed OAuth 2.1-aligned OIDC authorization server. That difference decides most of this comparison: Auth.js lets your app consume other people's identity providers, while NamoID is the identity provider your applications and APIs federate against.

For an Indian startup, three practical consequences follow. Auth.js has no built-in SAML enterprise SSO or SCIM, its default session mode cannot be revoked immediately, and it ships none of India's verification rails. NamoID covers all three, runs primary workloads in AWS Mumbai, and prices in rupees.

NamoID vs Auth.js at a glance

Decision	NamoID	Auth.js / NextAuth
What it is	Managed OIDC authorization server	Self-hosted relying-party library
Issues tokens to your APIs	Yes — scoped, audience-bound JWTs from one issuer	Not its role; it manages an app session
Enterprise SSO (SAML)	Platform capability, enabled per instance	Not built in; significant custom work
SCIM / directory sync	Ask about current status	Not built in
Session revocation	Server-side sessions, revocable	JWT sessions by default are not immediately revocable
Passkeys	Supported	Experimental
India KYC rails	DigiLocker, Aadhaar offline e-KYC, cKYC, Truecaller	None
India OTP rails	DLT-registered SMS, WhatsApp OTP	None
DPDP evidence	Append-only audit, consent records, export, retention	Build it yourself
Licence cost	Rupee plans from the India price book	Free, open source
Who operates it	NamoID	You

A library that consumes identity is not an identity provider

This is the distinction that matters most, and it is easy to miss because both produce a logged-in user.

Auth.js connects your application to identity providers — Google, GitHub, an email link — and maintains a session for that application. It is well designed for that job and it is free.

What it does not do is act as an authorization server. There is no issuer your other services can discover, no JWKS endpoint they can validate against, no audience-bound access tokens for your APIs. So the moment you have a second consumer of identity — a mobile app, an internal admin tool, a partner integration, a Python or Go service — each one needs its own answer, and they tend to diverge. See one OIDC issuer for India for what consolidating that looks like, and access token vs ID token for why the distinction is not cosmetic.

NamoID issues standard tokens from one issuer. A Next.js frontend, a FastAPI service and a Go worker all validate the same JWT the same way. If your product is one Next.js app forever, you will not feel this. If it becomes a platform, retrofitting an issuer is materially harder than starting with one.

The session-revocation problem

Auth.js uses JWT sessions by default and database sessions only when you configure an adapter. JWT sessions are faster because there is no database round-trip — and they cannot be invalidated immediately. The token stays valid until it expires.

That is a real operational limitation with two consequences for an Indian product:

Incident response. When an account is compromised or an employee leaves, "log them out now" is the first action you want. A stateless JWT session does not offer it.
DPDP obligations. Session control and the ability to terminate access are part of demonstrating you can actually stop processing someone's data. See authentication data retention and DPDP access, correction and erasure.

You can configure a database adapter and accept the round-trip, which is the right choice — but note that this is a decision you have to know to make. NamoID keeps sessions server-side with revocation, plus refresh-token rotation with replay detection so a stolen refresh token revokes its whole chain rather than quietly continuing to work.

Enterprise SSO is the wall

Auth.js has no built-in SAML SSO, no SCIM provisioning and no directory sync. Passkey support is experimental.

This matters on a specific date: the day your first enterprise customer says "we need SAML with our Okta." At that point you are building a SAML service provider yourself — metadata parsing, signature verification, assertion replay protection, unsafe-XML rejection, signing-key rotation that does not break live connections, and failing closed on expired state or a revoked connection. Every item there is a way to get enterprise SSO quietly wrong, and it is usually discovered mid-sprint against a customer deadline.

NamoID has organizations, memberships and SAML enterprise sign-in built into the platform. Stated plainly: customer organizations and enterprise SSO are implemented and enabled per instance rather than self-serve at signup, and Razorpay-backed customer billing is in final rollout. The day-one benefit is that when the SAML request arrives you are switching on something that exists. Confirm current availability for your instance before planning a launch around it.

"Free" is a licence, not a cost

Auth.js has no per-user bill, and for a solo project or an early prototype that is genuinely the right economics.

The cost that does not appear on a pricing page is everything you own: the session and user tables, provider breakage when an upstream OAuth app changes, upgrade paths, passkey and MFA implementation, recovery flows that resist support-desk social engineering, rate limits on auth endpoints so OTP floods do not become a billing attack, and the whole India layer below. The build-versus-buy analysis prices this honestly and deliberately refuses to give a single number, because auth never reaches "done", only "running".

For the record, Auth.js's own maintainers now point new projects at newer libraries rather than v5, so factor project direction into a long-lived decision. Verify its current status in its own documentation.

The India layer no library ships

Whatever you assemble in-app, none of this comes with it:

DigiLocker integration — OAuth consent redirect, listing issued documents, verifying a signed copy.
Aadhaar offline e-KYC XML — parsing the UIDAI-signed ZIP, verifying the signature, and masking so all twelve digits are never stored.
cKYC 2.0 — the central KYC registry as a real-time, consent-first API.
DLT-registered SMS — TRAI registration, template approval, deliverability and cost.
WhatsApp OTP and Truecaller verification.
DPDP audit evidence — append-only events, consent records, export and retention.

For an Indian product this is usually the larger engineering cost, and it is the part NamoID is built around. It is also the work that a free library makes look free right up to the point you start it — which is why DIY auth keeps failing at Indian startups.

The controls a security reviewer will ask about

Enforced in the platform and observable in behaviour:

PKCE on every authorization flow, including first-party clients; no implicit flow.
Refresh-token rotation with replay detection — a refresh token used twice revokes the entire chain and emits a security event.
Append-only audit events on state changes.
Aadhaar masked at rest — last four digits, a name hash and a signature-verification result only.
Provider tokens encrypted at rest with AES-256-GCM, never logged.
Rate limits on authentication and OTP endpoints.
Tenant-scoped queries so one workspace cannot read another's data.

Ask any vendor to demonstrate refresh-replay revocation and show the audit record it produces. Both are visible in a one-day proof.

Authorization is still yours

NamoID issues scoped tokens; your API validates issuer, audience, expiry and scopes, then applies its own rules. A token carrying invoices:read may permit the operation while your application must still confirm the invoice belongs to the caller's organization. Hiding a button is not authorization — call the endpoint directly with a low-privilege token and confirm the server refuses. See multi-tenant authentication for SaaS.

Decide with a working proof

If you are on Auth.js today and it works, this is not urgent. Revisit it when a second application appears, when an enterprise customer asks for SAML, or when you need to revoke a session immediately and discover you cannot.

Build a one-day proof: render the sign-in modal from @namoidhq/react, validate a token in your backend, protect two roles, revoke a session, inspect the audit event. Working examples for Next.js, Express, FastAPI, Go and Java are in namoidhq/namoid-examples. The Indian startup auth decision guide covers the wider shortlist.

Start free, or bring your stack to the NamoID Slack community.

NamoID is not affiliated with or endorsed by Auth.js or NextAuth. Auth.js capabilities were sampled in September 2026 from published sources and change frequently — verify current behaviour in Auth.js's own documentation before deciding. This article is product guidance, not legal advice or a promise of compliance.

Related posts