Both are open source. Only one of them is all of it.

Read only the badge and authentik wins this: MIT is about as permissive as a licence gets, and Apache 2.0 asks slightly more of you — a NOTICE file, a patent grant, attribution on modified files. But the badge is not the offer. The repository's own LICENSE carves out directories, and one of them is not open source at all.

The Enterprise licence says the code in that directory "may only be used in production" with a valid subscription for the correct number of seats, that it is "forbidden to copy, merge, publish, distribute, sublicense, and/or sell" it, and that any patch you write to it belongs to Authentik Security, Inc. You may read it and you may modify it for development and testing. That is source-available, and it is a normal open-core arrangement — but it is the opposite of what MIT implies, and it sits in the same tree.

How much of the product is behind it

You do not have to guess, because a running server will tell you. Each component endpoint reports a requires_enterprise flag per type. On a freshly started, entirely unlicensed 2026.8.5:

for t in providers sources stages propertymappings policies; do
  curl -s -H "Authorization: Bearer $AK_TOKEN" \
    "http://localhost:9000/api/v3/$t/all/types/" \
  | python3 -c 'import sys,json; d=json.load(sys.stdin); \
      print(len(d), sum(1 for r in d if r["requires_enterprise"]))'
done

Eleven of eighty-one is not a crippled product. The open-source tier covers OIDC, SAML, LDAP, RADIUS, SCIM, Kerberos, the proxy and browser-based remote access, and most teams will never touch the other eleven. The vendor's pricing page adds a few more items that are not component types — privileged access management, exportable reports, enhanced audit logging, RADIUS EAP-TLS, OAuth 2.0 authentication on SCIM endpoints — and lists the price: $5 per workforce user per month, $0.02 per customer account, billed annually, with Enterprise Plus starting at $20,000 a year.

The point is not that the price is high. Against a commercial IAM vendor it is low. The point is that it is a per-seat meter on software you are hosting yourself, and that is the exact thing most people are leaving when they go looking for a Keycloak alternative. Keycloak has no such tier: the project sells nothing, gates nothing, and counts nobody. Everything in it is Apache 2.0.

The part worth reading before you buy

The Enterprise code ships inside the ordinary container image and is enabled by a licence key, which is convenient and has one consequence worth planning for. If a licence expires, or your user count goes past what you bought, authentik records the state and escalates: a warning to admins after two weeks, to users after four, and after six weeks it puts the API into read-only mode. The middleware then refuses every unsafe API request with HTTP 400 and denied_license.

Read the exclusions before you panic, because they are generous: GET, HEAD, OPTIONS and TRACE always pass, the flow executor is explicitly exempt so logins keep working, user create and update keep working, and the licence endpoints keep working so you can fix it. It is a configuration freeze, not an outage. It also never applies to an unlicensed install — a pure open-source deployment has no licence to expire. But it is a failure mode that exists only because there is something to buy, and it is worth knowing about before the renewal rather than six weeks after it.

If every user will be created in the new system, skip this section. If they live in Active Directory today, or if an HR system needs to push them in, it is probably the deciding one.

Reading from a directory

authentik treats LDAP as a source: a scheduled inbound synchronization of users and groups, with group hierarchy, optional password synchronization, and the option to delete objects that have disappeared upstream. Password changes made in authentik are written back, through the Active Directory extended operation. Other attribute changes are not: the sync is inbound.

Keycloak treats LDAP as user storage, which is a different thing, and the 26.8 server administration guide defines the three edit modes:

• READ_ONLY — "You cannot change the username, email, first name, last name, and other mapped attributes… Password updates are not supported."
• WRITABLE — "You can change the username, email, first name, last name, and other mapped attributes and passwords and synchronize them automatically with the LDAP store."
• UNSYNCED — "Keycloak stores changes… in Keycloak local storage, so the administrator must synchronize this data back to LDAP," which is how you add attributes to users held in a directory you are not allowed to write to.

On top of that sit twelve LDAP mapper types on a stock 26.8.2 server, a Sync Registrations switch that creates new Keycloak users in LDAP, periodic full and changed-user synchronization, and a Kerberos bridge for desktop single sign-on.

Writing to everything else

SCIM is where this comparison has recently moved, and most pages on the subject are out of date. Both servers do SCIM 2.0; they point opposite ways.

Keycloak's SCIM API is off until you turn it on per realm, needs a confidential client, and validates that the access token's aud claim is the SCIM base URL — a detail that costs an hour if you miss it, because the failure is a 401 that looks like a permissions problem. Once it is on, its own ServiceProviderConfig reports PATCH and filtering supported, with bulk, sort and ETag not supported:

# Keycloak 26.8.2, after enabling SCIM on the realm and adding an
# audience mapper for http://localhost:8080/realms/master/scim/v2
curl -s -H "Authorization: Bearer $TOKEN" \
  http://localhost:8080/realms/master/scim/v2/ServiceProviderConfig

{"patch": {"supported": true},
 "filter": {"supported": true, "maxResults": 100},
 "bulk":   {"supported": false},
 "sort":   {"supported": false},
 "etag":   {"supported": false}}

The practical read: an organization with an existing directory, group-derived authorization and desktop SSO gets all of that from Keycloak as configuration, while authentik gives you the login and leaves the rest to its provisioning APIs. Going the other way, if what you need is to push users out to a dozen SaaS applications, authentik has that in the box and Keycloak needs our organizations extension. Our SCIM explainer covers the protocol itself, and Keycloak identity provider documentation covers the brokering side.

authentik is the better answer when:

• Half your estate does not speak OIDC. The proxy, LDAP, RADIUS and remote access providers are the whole reason authentik is popular in homelabs and small infrastructure teams, and they are genuinely good. Keycloak will not do this, and assembling the equivalent out of oauth2-proxy and friends is a real project.
• Nobody on the team writes Java, and the custom logic is more than a mapper. Saving a Python expression beats building a JAR.
• You need to push users out to SaaS applications and would rather that came with the server than with an extension.
• A reviewer is going to ask about current OpenID certification. authentik's is on a 2026 build. Keycloak's is on 18.0.0, from 2022.
• You want one box. If a single admin console covering SSO, the reverse proxy and remote access is the shape of system you want to operate, that is a coherent position and Keycloak does not offer it.

Keycloak earns it when:

• You do not want a per-seat meter on software you host. Apache 2.0 throughout, nothing gated, no licence to expire, no user count to reconcile, and no vendor who can change the terms of the half you depend on.
• There is a directory. Writable LDAP edit modes, registration sync back to LDAP, twelve mapper types, scheduled synchronization and Kerberos is a large amount of work to not have to do.
• Your security review has a list. PAR, CIBA, mTLS-bound tokens, private_key_jwt, RFC 9207, encrypted tokens — present and advertised at the defaults.
• You need to reach into the model. 139 provider interfaces, and a custom authenticator or user storage backend that is a first-class part of the server rather than a fork.
• The ecosystem is the point. A CNCF Incubating project with many independent vendors behind it is a different kind of bet from a single-vendor project, both for support and for hiring people who have already run it.

And the honest closing note, which applies to either choice: the operations bill is real, and neither of these is light. Keycloak is a JVM application with a database, a cache and an upgrade cadence; authentik is three containers, a Docker socket and two supported release trains at a time. Idle on a 2-CPU, 8 GB machine immediately after start, authentik's published compose stack came to about 688 MB across its three containers and Keycloak's quickstart to about 512 MB — with the caveat that Keycloak sizes its heap at 70% of the memory limit it is given, so that figure moves with the limit, and that the Keycloak number is development mode with an embedded database while authentik's includes a real PostgreSQL. Neither is a production sizing. The reflex that Keycloak is the heavy one does not survive measurement.

Running either well is a job. That is the argument for managed Keycloak at a fixed monthly price rather than a per-user meter. If you would rather run it yourself, we support teams who do, and we publish backport images for older Keycloak branches because upstream tags them without announcing them. If residency is driving the decision, our EU data residency page states where identity data sits and where it does not, including the parts that are not flattering.