Keycloak is the closest architectural match to NamoID in this category: a genuine authorization server speaking OpenID Connect, OAuth 2.0 and SAML 2.0. So protocol capability is not what separates them. What separates them is who carries the operational burden, and whether the platform speaks India.

With Keycloak you run a JVM identity service, its database, its high-availability story, its backups, its monitoring and its upgrades — permanently, because only the latest release is maintained. With NamoID that is someone else's pager, primary identity workloads run in AWS Mumbai, billing is in rupees, and India's verification rails ship with the product.

NamoID vs Keycloak at a glance

Decision	NamoID	Keycloak
Protocols	OAuth 2.1-aligned OIDC, SAML for enterprise sign-in	OIDC, OAuth 2.0, SAML 2.0
Who operates it	NamoID	You
Licence cost	Rupee plans from the India price book	Free, open source
Real cost	Subscription	Infrastructure, on-call, upgrades, expertise
Upgrade obligation	None on you	Only the latest release is maintained
Minimum footprint	None	~1 GB heap plus Postgres; ~2 GB RAM floor, 4 GB comfortable
India infrastructure	AWS Mumbai	Wherever you deploy it
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
Enterprise SSO	Platform capability, enabled per instance	Supported, you configure and operate it

The upgrade treadmill is the hidden commitment

Keycloak 26.7.0 shipped on 9 July 2026, and the project actively maintains only its latest version. There is no long-term-support branch in the community distribution. For a startup that means a permanent, non-negotiable upgrade cadence on the service that sits in front of every login in your product.

Two things follow. First, an auth outage is a full outage — nobody can sign in — so upgrades need a rehearsal environment, a rollback plan and a maintenance window. Second, falling behind is not a neutral choice: unpatched identity infrastructure is precisely where you least want known vulnerabilities. Since version 25 the distribution has been Quarkus-based rather than WildFly, which is a genuine improvement, and also an example of the kind of migration you inherit.

If you want a supported lifecycle instead, that means the Red Hat build of Keycloak, which brings its own support, entitlement and procurement considerations — a different conversation from "free and open source."

"Free" is a licence, not a cost

Keycloak charges nothing to download. Running it in production for real users costs:

Infrastructure. Budget roughly 1 GB of heap for Keycloak plus memory for PostgreSQL — about 2 GB of free RAM to start and 4 GB to be comfortable, per instance, before you add a second for availability.
On-call. Someone owns the pager for the service every login depends on.
Expertise. Realms, clients, mappers, authentication flows and the admin model are learnable but not obvious, and the knowledge tends to live in one engineer's head.
Upgrades, backups, restore rehearsals and monitoring, indefinitely.

The build-versus-buy analysis works through this and deliberately refuses to give a single figure, because an identity service never reaches "done", only "running". The honest framing is that Keycloak converts a subscription line item into an engineering commitment. Whether that trade is good depends on whether you have identity and platform engineers you are happy to spend on it — and whether identity operations is where you want your differentiation.

Keycloak is the right shape for a team that has that capacity and wants full control of the deployment. NamoID is the right shape for a team that would rather spend those engineer-weeks on the product only they can build.

What Keycloak does not know about India

This is the gap that no amount of operational skill closes, because it is product surface rather than configuration:

DigiLocker integration — the OAuth consent redirect, listing issued documents, pulling and 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 — India's central KYC registry as a real-time, consent-first API.
DLT-registered SMS — TRAI registration, template approval, and the deliverability and cost consequences.
WhatsApp OTP and Truecaller verification — the channels Indian users expect.
Account Aggregator consent — a signed, purpose-bound artefact rather than an OAuth token.
DPDP audit evidence — append-only events, consent records, export and retention per data class.

Each is a custom extension or a separate service you build and maintain beside Keycloak. Self-hosting also means residency is your responsibility rather than a vendor guarantee — which cuts both ways: deploy in Mumbai and you control it completely, but you also own the documentation, the subprocessor list and the evidence a customer's security review asks for. See data localization in India for what the rule actually requires.

What you are not building on day one

With NamoID, organizations, memberships, invitations and SAML enterprise sign-in are platform capabilities rather than a configuration project, and the India rails above are product surface rather than extensions you write.

Stated plainly: customer organizations and enterprise SSO are implemented in the platform 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 your first enterprise customer asks for SAML, or you are ready to charge, you switch on something that exists. Confirm current availability for your instance before planning a launch around it.

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 written to logs.
Rate limits on authentication and OTP endpoints, a billing control as much as a security one.
Tenant-scoped queries so one workspace cannot read another's data.

Self-hosting means each of these is a control you configure and verify yourself. Managed means it is a control you can ask to see demonstrated. Ask for the refresh-replay behaviour and the resulting audit record either way.

Authorization is still yours

Both products issue tokens; neither infers your business policy. 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. See multi-tenant authentication for SaaS.

Decide with a working proof

Because both speak OIDC, you can build the same proof against each and compare honestly: sign in, validate a token in your backend, protect two roles, revoke a session, inspect the audit event. Then add the two questions that decide it — who upgrades this service for the next three years, and what happens the day you need DigiLocker or Aadhaar verification.

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, and hosted versus embedded authentication covers the integration-model question.

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

NamoID is not affiliated with or endorsed by Keycloak or Red Hat. Keycloak versions, resource guidance and features were sampled in September 2026 from published sources and change frequently — verify current details in Keycloak's own documentation before deciding. This article is product guidance, not legal advice or a promise of compliance.

Related posts