This post is not a case for Keycloak. It's the comparison we'd walk a CTO through if they had to make the decision in the next 30 days.

The Context That Changed Everything

In 2021, Okta acquired Auth0 for $6.5 billion. What followed was predictable: plan restructuring, tier elimination, and price increases that caught many companies off guard — companies that had built their identity architecture on Auth0.

This isn't a criticism — it's the logic of any acquisition at that scale. But for a CTO evaluating their identity stack today, it means the Auth0 economics of 2019 are not the economics of 2026.

That's what's pushing many companies to reopen this conversation.

The Real Cost Model

Auth0 charges by MAU (Monthly Active Users) — users who authenticate at least once per month. That sounds reasonable until you calculate what happens as you grow.

Auth0 pricing varies by plan and changes frequently. Verify on their website before comparing.

With Keycloak, the cost is infrastructure (servers, database, monitoring) plus the team that operates it — internal or external. Beyond a certain volume, the difference is significant.

Control vs. Managed Service

This is the real tension, and it has no universal answer.

Auth0 gives you:

• Very fast time to production — hours, not weeks
• Managed infrastructure, no on-call rotations for your IDP going down
• Excellent documentation and a developer experience few tools can match
• Automatic security updates

Keycloak gives you:

• Full control over authentication flows, token structure, and access policies
• Real extensibility — you can modify almost any behavior through SPIs and extensions
• No MAU limits or surprise invoices
• Deployment flexibility — on-premises, your cloud, or any regulated environment

The question is not which is better in the abstract. It's whether your organization has — or can get — the operational capacity to take advantage of that control.

Data Sovereignty: The Factor Most Companies Overlook

With Auth0, your users' identity data — emails, metadata, session history — lives on Okta's servers. For many companies, this isn't a problem. For others, it is.

Situations where it matters:

• GDPR in the EU: you need to know exactly where data lives and be able to demonstrate international transfer compliance
• Regulated sectors (banking, healthcare, government): data residency requirements may directly rule out third-party SaaS solutions
• Enterprise customers: some contracts include clauses restricting where authentication data is processed

With Keycloak, data lives where you decide. Full stop.

The Risk Nobody Measures: Vendor Lock-in

Auth0 is built on open standards — OIDC, OAuth 2.0, SAML. In theory, migrating should be possible.

In practice, the lock-in comes from elsewhere:

• Business logic encoded in Actions (Auth0's proprietary scripting system)
• Hooks and login flows built with their specific UI
• User metadata in their data structure
• Integrations with their marketplace

Migration isn't impossible, but it carries a real cost in engineering time. And that cost grows every year you keep building on the platform.

With Keycloak, the standard is at the center of everything. If you ever want to switch, the protocol — OIDC, SAML — is yours and portable.

When Auth0 Makes Sense

Let's be clear: there are scenarios where Auth0 is the right choice.

• Early-stage startup that needs authentication in production this week, with no infrastructure team
• MVP or proof of concept where speed is everything and cost isn't the constraint
• B2C SaaS product with a small, stable user base
• Team without infrastructure operations experience and no budget for a specialized partner

In these cases, Auth0's simplicity and speed outweigh the cost and dependency. There's no point running Keycloak if you don't have the conditions to run it well.

When Keycloak Wins

• Regulated sector — banking, healthcare, insurance, government — where data sovereignty is non-negotiable
• Complex architecture requiring custom authentication flows, identity federation, or legacy system integration
• Multi-tenant strategy with per-customer isolation requirements
• Technical teams with infrastructure operations capacity, or access to a specialized partner to handle it for them

In these scenarios, the control Keycloak provides doesn't just justify the operational cost — it surpasses it.

The Decision

If you're evaluating this now, the most useful question is not "which one is better?" but "what will cost us more in three years: operating Keycloak or depending on Auth0?"

That answer depends on your user volume, your sector, your team, and your tolerance for dependency on an external vendor.

If you want to work through the numbers with your specific context, let's talk.

At IDPTrust we are Keycloak specialists. If you're in the middle of this decision, we can help you evaluate your options without bias.

Auth0 / Okta

✅ Fastest time to production. Best developer experience and documentation in the market.
✅ Managed service — no infrastructure to operate or maintain.
❌ Pricing scales aggressively with MAUs. Painful at 50k+ users.
❌ Limited control over authentication flows and token structure.

Best fit: startups and SaaS products that need IAM fast and can absorb the cost.

→ See the detailed Keycloak vs Auth0 comparison

Microsoft Entra ID

✅ Seamless with the Microsoft stack — M365, Teams, Azure, Dynamics.
✅ Effectively free if you're already paying for M365 E3/E5.
❌ Outside the Microsoft ecosystem, integration complexity increases significantly.
❌ Licensing tied to Microsoft 365 plans — hard to decouple if your stack changes.

Best fit: organizations fully committed to Microsoft, with limited need for non-Microsoft app federation.

Authentik

✅ Modern UI, easier to operate than Keycloak for straightforward use cases.
✅ Open source with active development and a growing community.
❌ Less mature for enterprise scenarios — limited SAML support, fewer extension points.
❌ Smaller ecosystem and less community knowledge available.

Best fit: smaller teams wanting self-hosted IAM without Keycloak's operational weight.

Ping Identity

✅ Purpose-built for large enterprise hybrid environments — strongest on-prem + cloud mix on the market.
✅ DaVinci orchestration engine for no-code authentication flow design.
✅ Strong compliance tooling: GDPR, HIPAA, SOX, PCI DSS out of the box.
❌ Premium pricing — workforce plans from $3–6/user/month, CIAM from $35k/year.
❌ Complex deployments: 2–4 months basic, 6–12 months for large rollouts.
❌ OIDC custom attribute configuration has known friction points.

Best fit: large enterprises with hybrid environments and complex Active Directory infrastructures.

One Identity

✅ Strong IGA — automated provisioning, access certification, role-based controls.
✅ Excellent Active Directory management via Active Roles — most praised product in their suite.
✅ Wide library of out-of-box connectors for SAP, Oracle, Exchange, and more.
❌ Suite of separate products rather than a unified platform — evaluation and licensing get complicated.
❌ UI is dated and has a reputation for being slow in large environments.
❌ Heavy implementation effort; backend development still depends on VB.NET in parts.

Best fit: large enterprises with complex IGA needs, significant AD footprint, and tolerance for implementation complexity.

Keycloak

✅ Most complete open-source IAM platform — OIDC, SAML, LDAP, fine-grained authorization, custom SPIs.
✅ No per-user licensing. Your infrastructure, your data, your costs under control.
✅ Enterprise-proven at millions of users. CNCF incubation project.
❌ Operational overhead is real — upgrades, HA, and performance tuning require expertise.
❌ Native console has limits: bulk user management, persistent audit logs, and contextual access need extensions.

Best fit: mid-to-enterprise organizations that need full control, complex federation, or operate in regulated environments where data residency and licensing cost matter.

The honest summary

What drives your IAM platform decision?

At IDPTrust we specialize in Keycloak in production. If you need help choosing the right IAM platform or deploying Keycloak at scale, get in touch.

Here is what changed and why it matters for teams running Keycloak in production.

Five features graduate from preview to supported

JWT Authorization Grant (RFC 7523)

External-to-internal token exchange using signed JWT assertions.

A client can present an externally signed JWT assertion — issued by a trusted external authority — and obtain an OAuth 2.0 access token from Keycloak without a separate client secret. This is particularly relevant for service-to-service authentication across trust domains, where sharing secrets is impractical or where an external issuer (another IdP, a Kubernetes cluster, a cloud provider) is the natural source of identity.

Federated client authentication

Clients authenticate using existing trust relationships — no more per-client secrets.

Clients can now authenticate to Keycloak using an existing trust relationship with an external issuer, including OIDC identity providers and Kubernetes Service Accounts. In environments where dozens of microservices each hold their own client secret, this eliminates both the management overhead and the rotation risk.

Note: OAuth SPIFFE Client Authentication remains in preview as the spec is still in draft.

Workflows

IGA capabilities — natively in Keycloak, defined in YAML.

Workflows allow administrators to automate realm administrative tasks using YAML-defined pipelines triggered by events, conditions, or schedules. Supported operations include user and client lifecycle management — provisioning, deprovisioning, and state transitions.

This is the most significant feature of this release for regulated environments. It brings Identity Governance and Administration (IGA) capabilities natively into Keycloak, reducing the need for external tooling to automate identity processes such as joiner/mover/leaver flows.

Zero-downtime patch releases

Rolling upgrades within the same major.minor stream — enabled by default.

Rolling updates within the same major.minor stream are now supported without service interruption. This is enabled by default. On Kubernetes with the Keycloak Operator, set the update strategy to Auto to benefit automatically.

Important: this applies to patch version upgrades only (e.g. 26.5.5 → 26.5.7). Minor version upgrades (26.5 → 26.6) still require a planned maintenance window.

Keycloak Test Framework

JUnit 6 — replaces Arquillian + JUnit 4.

The new framework handles the lifecycle of Keycloak, the database, and injected resources transparently. Relevant for teams building custom SPIs or extensions.

Other changes worth noting

• Java 25 support — Keycloak now runs on OpenJDK 25. The container image continues to use OpenJDK 21 for FIPS compatibility.
• KCRAW_ env var prefix — Values containing $ characters injected via Kubernetes secrets were silently mangled by SmallRye expression evaluation. KCRAW_ preserves the value exactly as provided.
• LDAP forced password change — Keycloak now respects the LDAP server's "must change password" control. Previously users were let through without being prompted.
• Graceful HTTP shutdown — Connection draining during shutdown before terminating, reducing error responses during rolling restarts.
• MCP authorization server (experimental) — Keycloak can now act as authorization server for Model Context Protocol version 2025-11-25+.
• Token Exchange V1 deprecated — Plan your migration to V2.

Should you upgrade?

Yes, and there is no urgency — this is not a security release. Plan the upgrade within your normal maintenance window.

If you are running Keycloak on Kubernetes with the Operator, zero-downtime patch updates are now enabled by default, which simplifies future upgrades within the 26.x stream.

Full release notes: keycloak.org/2026/04/keycloak-2660-released

At IDPTrust we specialize in Keycloak in production. If you need help assessing this release or planning an upgrade, get in touch.

Here is a breakdown of what was fixed and how severe each issue is.

Critical — patch immediately

CVE-2026-4282 · CVSS 7.4 (High) — Privilege escalation via forged authorization codes

The SingleUseObjectProvider component, a global key-value store used internally by Keycloak, lacks proper type and namespace isolation. An unauthenticated attacker can exploit this flaw to forge authorization codes and use them to obtain admin-capable access tokens — without credentials and without user interaction.

This is the most dangerous vulnerability in this release. No authentication required, no user interaction required, and successful exploitation gives an attacker full administrative control over your Keycloak instance.

What to check: Review any external network exposure of your Keycloak endpoints. Ensure your instance is updated before anything else.

CVE-2026-3872 · CVSS 7.3 (High) — Redirect URI validation bypass via path traversal

A flaw in how Keycloak validates redirect URIs with wildcard patterns allows an attacker who controls any other path on the same web server to bypass the allowed-path restriction using a ..;/ sequence in the OIDC authorization endpoint. A successful exploit leads to access token theft.

What to check: If your Keycloak instance shares a hostname with other applications, this is especially relevant. Review your redirect URI configurations and ensure wildcard patterns are as restrictive as possible.

High — review your setup

CVE-2026-4636 — UMA policy injection allows cross-user permission grants

An authenticated user can inject a resource reference into a UMA policy in a way that grants them unauthorized access to resources owned by other users. Affects deployments using UMA 2.0 for resource sharing.

CVE-2026-3429 — Improper LoA control during credential deletion (Account API)

The Account REST API does not properly enforce the required Level of Assurance when a user deletes a credential. This can be exploited to remove MFA factors and take over an account without meeting the authentication requirements the policy requires.

CVE-2026-4634 — Application-level DoS via scope processing

Keycloak does not adequately limit the processing of OpenID Connect scope parameters. An unauthenticated attacker can send crafted requests that cause excessive processing, degrading the availability of the instance without requiring any credentials.

Moderate

CVE-2025-14083 — Information disclosure via Admin REST API

A user holding only the create-client permission — considered low-privilege by design — can access the /admin/realms/master/users/profile endpoint and read internal user profile schema data, including attribute names, validation rules, and permission mappings.

CVE-2026-1002 — Vert.x static file cache manipulation

The static file handler in the underlying Vert.x framework can have its cache manipulated in a way that denies legitimate access to static resources. Upgraded in this release via the Quarkus 3.27.3 dependency update.

Additional changes

• Quarkus upgraded to 3.27.3.
• One bug fix: calls without a Host header no longer throw an uncaught error.

Should you update?

Yes, and soon. Two of these CVEs require no authentication to exploit. The attack surface is any Keycloak instance reachable over the network.

If you are running a version older than 26.5.7 — or worse, still on a WildFly-based distribution — this release is a good reminder that staying current is not just good practice, it is a security requirement.

Full release notes: keycloak.org/2026/04/keycloak-2657-released

At IDPTrust we specialize in Keycloak in production. If you need help assessing the impact of this release on your setup or planning an upgrade, get in touch.

Severity: Moderate
Affected package: org.keycloak:keycloak-services (Maven)
Affected versions: > 26.2.0, < 26.2.6 (only when FGAPv2 is enabled)
Patched versions: 26.2.6 and 26.3.0

What’s the issue?

A flaw in the admin permission enforcement allows a user with manage-users privileges to self-assign realm-admin when FGAPv2 is enabled in Keycloak 26.2.x.
Root cause: missing privilege boundary checks during role mapping via the Admin REST API.
Impact: a malicious limited admin could escalate to full realm administration, including realm configuration and user data access.

Who is affected?

• Deployments on Keycloak 26.2.x with FGAPv2 enabled.
• Environments on 26.2.6+ or 26.3.0 are not affected.

Our status (IDPTrust)

• All managed customers have been notified.
• Patch windows are scheduled across all environments (dev, staging, production) to move to 26.2.6 or 26.3.0 depending on compatibility.
• We are verifying FGAPv2 usage per realm and tightening admin role boundaries.

Recommended actions

1. Upgrade to 26.2.6 or 26.3.0 as soon as feasible.
2. If you cannot upgrade immediately:
   • Disable FGAPv2 temporarily if your deployment allows it.
   • Review admin user assignments; ensure no user with limited rights can edit their own role mappings.
   • Restrict access to the Admin REST API and audit its usage.
3. Audit recent admin role changes for suspicious self-assignments.

How to check your deployment

• Confirm your Keycloak version: Admin Console → Server Info or image tag.
• Check whether FGAPv2 is enabled in your realm/installation notes.
• Review Admin Events for role-mapping changes on admin users.

Timeline

• Advisory published: Jul 29, 2025 (by rmartinc).
• IDPTrust notification & patch scheduling: 2025-07-29.

For questions or help planning the update, contact your IDPTrust support channel.

Severity: Moderate
Affected package: org.keycloak:keycloak-services (Maven)
Affected versions: <26.0.13, <26.2.6
Patched versions: 26.2.13, 26.2.6, 26.3.0

What’s the issue?

There is a flaw in the first login flow during an IdP login. An attacker who already has a registered account can initiate account linking with a victim’s existing account. During the subsequent “review profile” step, the attacker can change their email address to the victim’s email, triggering a verification email sent to the victim. If the victim clicks the verification link, the attacker may gain access to the victim’s account.

While this is not a zero‑interaction attack (the victim must click the verification link), the attacker’s email is not surfaced in the verification email, making this scenario a phishing opportunity.

Impact

• Potential account takeover if the victim clicks the verification link sent during the attacker‑initiated flow.
• Affects deployments running vulnerable versions listed above.

Our status (IDPTrust)

• All managed customers have been notified.
• Patch windows are scheduled across all environments (development, staging, production) to move to the patched versions listed by the advisory.
• We are auditing account linking and email verification flows and strengthening monitoring around Admin Events and login flows.

Recommended actions

1. Upgrade to a patched version as soon as possible (26.2.13, 26.2.6, or 26.3.0, per the advisory).
2. Until you upgrade:
   • Consider disabling or restricting account linking where feasible.
   • Educate users to be cautious with unexpected email verification requests.
   • Review IdP first‑login configuration and ensure additional safeguards (e.g., manual review) where appropriate.
3. Audit recent login/account‑linking events for suspicious activity.

How to check your deployment

• Confirm your Keycloak version (Admin Console → Server Info, or your image tag).
• Review your First Login Flow steps for IdP logins, especially “review profile” and email verification behavior.
• Inspect logs and Admin Events around account linking attempts.

Timeline

• Advisory published: Jul 29, 2025 (by rmartinc).
• IDPTrust notification & patch scheduling: 2025-07-29.

References

• Official advisory: GHSA-xhpr-465j-7p9q – Phishing attack via email verification step in first login flow
  https://github.com/keycloak/keycloak/security/advisories/GHSA-xhpr-465j-7p9q