There are systems you can ‘quickly’ outsource. And there are systems that are something like the backbone of your entire digital infrastructure. Identities and permissions clearly belong to the second category for me.
If your identity provider (IdP) wobbles, everything wobbles: VPN, email, Git, Kubernetes, Atlassian, HR tools, password manager, cloud console—and, in case of doubt, even your break-glass access. Identity is not just ‘login.’ Identity is governance, access, audit, incident response. And with that: sovereignty.
Authentik (yes, lowercase in the project) positions itself precisely in this space as an open-source IdP for modern SSO—self-hostable, from homelab to cluster, with SAML, OAuth2/OIDC, LDAP, RADIUS, and more.
Why you should operate your authentication yourself as the backbone of your entire digital infrastructure
1) Data sovereignty isn’t a buzzword — it’s an operating model
At Honicon, we have already made this choice very consciously for other ‘foundation services’: Data should not run ‘somewhere’ through third-party servers just because it’s convenient. The point isn’t paranoia—the point is control: What logs are created? Where are they stored? Who can see them? How quickly can I access them in an emergency?
With an IdP, this is even more acute:
- Login metadata is gold (who, when, where, with what, from which device/IP, which app).
- Policies are power (who may do what, under which conditions).
- Audit trails are liability (traceability, auditability, incident timeline).
If identity is ‘cloud-only,’ your sphere of control is automatically smaller—even if the provider is technically excellent.
2) Vendor lock-in doesn’t happen suddenly — it happens quietly
Lock-in is rarely a ‘we can’t leave.’ Lock-in is more like:
- The pricing model changes, and suddenly every security feature becomes ‘P2,’ ‘Advanced,’ ‘Premium.’
- You adapt your processes to the vendor (‘that’s just how it’s done here’).
- Your apps depend on proprietary features instead of standards.
Authentik deliberately relies on standard protocols (SAML, OIDC/OAuth2, LDAP etc.). It sounds boring—but it’s the trick that keeps you able to act in five years.
3) Resilience: If your IdP is down, your company is… offline
A self-hosted IdP doesn’t automatically mean ‘more downtime.’ On the contrary: you can build it for the availability you truly need—from a simple Docker setup to Kubernetes/Helm operations.
And for environments that can’t ‘just reach the internet’ (firewalled, segmented networks, sites), Authentik brings the concept of Outposts that support exactly such scenarios.
4) Security: Zero Trust starts with identity, not with the firewall rule set
Microsoft describes Conditional Access as a ‘Zero Trust policy engine’ that collects signals and enforces policies. The point is correct—but this engine doesn’t necessarily have to live in the cloud.
Authentik thinks with flows, stages, and policies in modular building blocks: authentication, enrollment, recovery, approvals—as composable workflows.
Critical reality check: Self-hosting also means patching, monitoring, backing up, hardening, and testing yourself. If you don’t take that seriously, ‘cloud’ is sometimes objectively the better choice. Sovereignty isn’t a free buffet—it’s responsibility.
How Authentik stacks up against other open-source authentication solutions (e.g., Keycloak)
Keycloak is the top dog in open-source IAM. Deservedly so. Huge community, long history, enterprise-proven. Keycloak also relies heavily on standards like OpenID Connect and SAML 2.0.
So why Authentik?
1) Pragmatism and a ‘glue’ mentality instead of pure IdP dogma
Authentik calls itself ‘authentication glue’—and that’s accurate: It doesn’t just want to ‘issue tokens,’ but to glue apps together in heterogeneous landscapes.
That includes things like:
- Proxy/application gateway approach for apps without SSO capability (provider/proxy, outposts).
- SCIM as a provider for provisioning into target systems.
Keycloak can do an enormous amount—but you often end up more quickly in an ‘IAM project’ rather than with a solution you can operate cleanly alongside day-to-day business.
2) Flows/staging: visual workflows instead of ‘configuration archaeology’
Authentik makes its building-block philosophy quite explicit: flows + stages + policies are ‘at the heart’ of the system.
That’s not just UX—it’s a different mindset: You model sign-in and security logic as a process.
Keycloak is also flexible, but many teams experience the flexibility more as: ‘There are three ways, and all of them have gotchas somewhere.’
3) Broad protocol coverage, including legacy anchors
In addition to OIDC/SAML, Authentik lists LDAP and further integrations as standard providers.
Especially in German midmarket landscapes, ‘legacy’ isn’t a dirty word but reality: NAS, print services, older VPNs, device access. It helps if the IAM can not only do web SSO but also build bridges.
4) MFA and modern authenticators: TOTP and WebAuthn/passkeys
Authentik includes stages for TOTP and WebAuthn/passkeys.
This matters because ‘MFA on’ isn’t the same as ‘phishing-resistant.’ WebAuthn/passkeys are a real security lever when rolled out sensibly.
Critical reality check: Keycloak has enormous adoption, integration breadth, and market know-how in large enterprises. If you have a team that truly knows Keycloak—or already a Java/Quarkus-adjacent ecosystem—Keycloak can be the better choice. Authentik often wins where teams need speed + clear modeling + ‘glue.’
How Authentik compares to proprietary solutions like Entra ID or Okta
Let’s be fair: Entra ID and Okta aren’t successful because everyone in procurement is asleep. The products are strong—especially if you play precisely in their ecosystems.
Microsoft Entra ID: brutally good in Microsoft environments — and very powerful via Conditional Access
Entra ID supports SSO via OIDC and SAML (Microsoft documents both very comprehensively) and offers Conditional Access as the central policy engine.
If you are heavily invested in M365/Azure, Entra is often ‘the natural gravity.’
Where Authentik scores instead:
- You want identity not as part of a single hyperscaler stack, but as an independent security domain.
- You want to use standard protocols so that a later switch doesn’t become open-heart surgery.
- You want to design workflows/enrollment/policies yourself, without every feature being tied to a license tier (realistically: a frequent pain).
Okta: very mature, very broad, but (like any major provider) an attractive target
Okta is a powerful IdP; OIDC and SAML are also central integration paths there.
But: identity providers are high-value targets. And Okta had, among other things, the publicly discussed support system security incident (October 2023)—Okta itself published updates and recommended actions, and reporting showed that the reach was greater than initially communicated.
This isn’t ‘Okta-bashing.’ It’s the sober realization: If you buy a central IdP, you also buy its risk profile —including transparency, incident communication, third parties, and support processes.
Where Authentik scores instead:
- You can define operations, logging, access to support data, admin processes, and key material yourself.
- You reduce the number of external parties through which identity data and token flows ‘pass.’
Critical reality check:
Cloud IdPs often win at:
- extremely rapid scaling,
- very deep SaaS integrations,
- ‘Device + identity’ combinations (compliance, managed devices),
- procurement/standardization (‘one contract, one portal’).
Authentik often wins at:
- sovereignty,
- cost and model control,
- integration freedom in mixed landscapes,
- on-prem/hybrid/segmented networks (Outposts).
| Criterion | Authentik | Keycloak | Entra ID / Okta |
|---|---|---|---|
| Sovereignty | ✅ Fully self-controlled | ⚠️ Dependent on community/Red Hat | ❌ Cloud dependency |
| Legacy integration | ✅ LDAP, RADIUS, Outposts, SCIM, Kerberos | ⚠️ LDAP, SAML, OIDC (limited) | ❌ Focus on modern protocols |
| Operational effort | ⚠️ Own responsibility (Kubernetes, Docker, Terraform) | ⚠️ Complex (Java/Quarkus, clusters) | ✅ Managed service |
| Admin training | ⚠️ Skills in IAM, Kubernetes, IaC (Infrastructure as Code) | ⚠️ Java/Quarkus, IAM, cluster management | ✅ Cloud certifications (e.g., Azure/Okta) |
| Core topics | ✅ Open source, workflow automation, self-hosting, FIPS compliance, WebAuthn/passkeys, GeoIP, application proxy | ✅ Open source, OIDC/SAML, community support | ✅ Enterprise support, deep SaaS integration, Conditional Access |
| MFA & modern auth | ✅ WebAuthn/passkeys, TOTP, GeoIP | ✅ TOTP, WebAuthn (plugin-based) | ✅ WebAuthn, adaptive MFA |
| Remote access | ✅ RDP, VNC, SSH | ❌ Not native | ⚠️ Via third parties |
| Protocol support | ✅ OIDC, SAML, LDAP, RADIUS, SCIM, Kerberos | ✅ OIDC, SAML, LDAP, SCIM | ✅ OIDC, SAML, SCIM (no RADIUS) |
| Pricing model | ✅ Transparent, no hidden costs | ✅ Open source (paid support) | ❌ Complex, feature-based costs |
| Scalability | ✅ Kubernetes, Terraform, Docker Compose | ⚠️ Cluster-based | ✅ Automatic scaling |
| Use cases | ✅ Authentication, enrollment, self-service, B2B/B2C | ✅ Authentication, B2B | ✅ B2B/B2C, enterprise IAM |
The right decision is rarely ‘cloud good / self-host good,’ but rather: Which dependencies are acceptable for you—and which are not?
Manage identities and permissions smartly yourself—without hype, without dependency
At Honicon, we eventually understood: Identities and permissions are not just a technical topic—they are a process topic. And that’s exactly where many implementations fail: SSO works, MFA works, all neat—but the question ‘Who gave whom access when and why?’ ends at best in a wiki fragment and at worst in shrugs.
That’s why we don’t use authentik in isolation, but as part of our workflows—coupled with our daily work tools: Atlassian Jira and Plane.so. The idea is simple:
- Identities, roles, and access requests are not decided ‘somewhere,’ but handled as a traceable process.
- Approvals happen where people are already working (tickets/requests, responsibilities, four-eyes principle, deadlines).
- And the best part: The documentation and evidence for the ISMS practically falls out as a by-product—because decisions, rationales, changes, and reviews are already created in the process instead of being laboriously added later.
If you take sovereignty seriously, don’t start with the hundredth app integration, but with the question: How do we make access decisions—and how do we prove them?
If you like, we’ll review your landscape together (apps, standards, legacy, responsibilities) and build a solution that doesn’t just ‘do login,’ but also operations, audit, and ISMS from the start—without artificial extra effort, but with real control.