Keycloak vs authentik for AI Platforms: A Compliance Perspective

Both are capable identity providers. The differences that matter show up in your SOC 2 evidence package and in how you authenticate agents.

Most Keycloak-versus-authentik comparisons are written for the wrong reader. They weigh setup time, memory footprint, and how pleasant the admin UI is. Those are reasonable criteria for a homelab and almost irrelevant to a team building an AI platform that has to pass a SOC 2 Type II audit and authenticate non-human identities.

We evaluated both for exactly that use case. This is what the comparison looks like when you filter it through three questions: can you produce audit evidence, can you manage the whole configuration as code, and can it authenticate agents rather than just people.

Start With the Right Frame

Neither tool is SOC 2 certified, and neither can be. They are open source projects, not service organizations — certification applies to your company and your controls, not to a container image you deployed. Any vendor claiming otherwise is confusing the boundary.

What an identity provider can do is make your controls demonstrable. In a SOC 2 audit, the questions that hurt are rarely about whether you have access control. They are about whether you can prove it: who granted this role, when, on whose approval, and can you show me the record for a date I choose. Your IdP either produces that evidence as a byproduct of normal operation, or your team assembles it manually every audit cycle.

The Comparison That Matters

Read that table honestly and one thing stands out: on general capability these tools are closer than the discourse suggests. Both do SSO, MFA, OIDC, SAML, and LDAP. The separation appears only when you apply compliance and agent-auth pressure.

Audit Trails: The Distinction Auditors Actually Care About

A common mistake is to treat “it has an audit log” as a checked box. Auditors do not ask whether events are logged. They ask you to produce the record of a specific administrative action from four months ago, and then they ask what would have happened if someone had wanted to delete it.

Keycloak separates admin events from user login events, which matters more than it sounds. Admin events capture configuration changes — role assignments, client creation, permission modifications — with the representation of what changed, the authenticated actor, and a timestamp. That maps directly onto the control language of a SOC 2 report, because privilege change is the thing being evidenced. Retention is configurable per realm, and the events are queryable through the Admin REST API, which means evidence collection can be scripted rather than screenshotted.

On immutability, be careful with the claim. No IdP writing to its own relational database is inherently immutable — a sufficiently privileged operator can alter rows. Immutability comes from the export path, not the storage engine. What Keycloak’s Event Listener SPI gives you is a supported hook to stream every event to append-only external storage: a SIEM, an object store with retention lock, a WORM bucket. That architecture is what satisfies an auditor, and the SPI is what makes it a configuration exercise rather than a patching exercise.

authentik logs events too. The gap is not presence, it is the maturity of the export and query path, and the amount of custom work needed to get evidence into a form an auditor accepts on the first pass.

Infrastructure as Code: Correct the Overstatement

We went into this evaluation expecting IaC to be a clear Keycloak advantage. It is not, and it is worth saying so plainly.

Both projects have first-party Terraform providers. Keycloak’s was originally community-built by Michael Parker and was formally adopted into the Keycloak organization in December 2024, moving from mrparkers/keycloak to keycloak/keycloak. authentik’s provider is maintained under goauthentik/authentik and covers most of the configuration surface.

What actually matters for compliance is not which provider exists but what the practice buys you. When realms, clients, roles, and mappers are declared in Terraform and applied through CI:

• Every configuration change has a pull request, a reviewer, and a timestamp — change management evidence generated automatically.
• terraform plan against production answers “does the running configuration match what was approved” in seconds. That is drift detection, and auditors ask for it.
• Environments are reproducible, so “our staging IdP is configured like production” becomes a verifiable claim.
• Nobody has to click through an admin console in production, which removes the most common source of undocumented change.

Pick either tool and adopt this practice and you are better off than a team that picked the “more compliant” tool and configures it by hand. The practice is the control; the provider is just the mechanism.

Agent Authentication: Where the Gap Is Real

This is the dimension where the two genuinely diverge, and it is the one most relevant to an AI platform.

Non-human identity is not a new idea — service accounts and client credentials have existed for years, and both tools support them. What is new is the specific shape agent authentication has taken. The Model Context Protocol’s November 2025 revision requires remote MCP servers to implement OAuth 2.1 with PKCE, and as of the 2025-11-25 spec version, MCP requires the authorization server to comply with OAuth Client ID Metadata Document (CIMD) for dynamic client registration.

Keycloak has been tracking this closely. Version 26.5 shipped a guide for using Keycloak as an authorization server for MCP servers, plus JWT Authorization Grant support for external signed assertions. 26.6 added CIMD support explicitly in response to the MCP requirement. 26.7 added integration documentation for Claude Code as an MCP client alongside the existing VS Code integration, and introduced token exchange delegation as an experimental feature for the case where a backend service acts on behalf of a user at another service.

That last one is the agent problem in miniature. When an agent calls a downstream API, the audit record needs to answer two questions at once: which agent acted, and on whose authority. A single client-credentials token answers the first and loses the second. Delegation semantics preserve both, which is exactly what you need when an auditor asks who authorized a given action.

authentik can authenticate machine clients perfectly well through standard OAuth2. What it does not currently publish is comparable MCP-specific guidance or the delegation primitives. For a general SaaS platform that gap may never matter. For a platform whose entire product is agents calling tools on behalf of users, it is the central requirement rather than an edge case.

The Role Model in Practice

One practical note for AI platforms specifically. The role structure most teams need looks like admin, editor, viewer — and then, separately, agent.

The temptation is to model an agent as a user with a role. It is the wrong shape. An agent is a distinct principal with its own credential lifecycle, its own scope set, and usually a much shorter token lifetime than a human session. Keycloak’s separation of client roles from realm roles, plus composite roles, expresses this cleanly: the agent client gets narrowly scoped tool permissions, the human roles govern the console, and the two never accidentally inherit from each other.

Whichever tool you choose, make agent a first-class principal type in your model rather than a user with a flag. The audit story is much easier to tell afterward.

What We Recommend

For an AI platform preparing for SOC 2, Keycloak is the stronger choice — not because authentik is a weak product, but because two specific things line up: the admin event stream plus Event Listener SPI gives you an evidence pipeline that maps onto audit language with little custom work, and the MCP and delegation work puts agent authentication on documented, standards-tracking ground rather than a pattern you invent yourself.

The honest trade-off is operational weight. Keycloak needs more memory, more upgrade discipline, and a real investment in understanding its data model before your team is productive. If your platform does not authenticate agents, is not pursuing SOC 2 in the next year, and your team is small, authentik will get you to a working identity layer considerably faster, and that is a legitimate choice.

Just make it deliberately. Identity is the hardest layer to migrate later — there is no automated migration path between these two, and application registrations have to be recreated by hand. Choosing on setup convenience and discovering the audit requirement eighteen months later is an expensive way to learn what your evaluation criteria should have been.

Talk to us at findustries.co/contact if you’re working through identity architecture for an AI platform heading into audit.