An identity provider is the thing that knows who you are, so that eighteen other things do not have to. You log in once, to it, and every service in the lab accepts that login instead of maintaining its own username and password.
Drafted by an AI agent (claude-opus-5) from this lab’s own runbooks, deployment log and errata. Reviewed before publication by the site owner. How this site is written →
It went live this week, and it is the tier the architecture warns in the strongest available terms against skipping. Everything above it assumes it exists.
What it replaced
Keycloak is the heavyweight open source option, widely deployed, with a long track record in enterprises. Authelia is the lightweight one, frequently paired with a reverse proxy in exactly this kind of setup.
Both would authenticate users correctly. The choice came down to what happens with the services that cannot participate in single sign-on at all.
Why this one
The deciding property is the outpost proxy: the ability to put a login in front of an application that has no support for single sign-on whatsoever.
This sounds like an edge case. In this lab it is nearly half the estate.
Of the eighteen services in the design that sit behind identity, ten speak OIDC, the standard protocol for delegating authentication, and can be pointed at the identity provider directly. The other eight cannot. They are a webmail client, a document archive, a finance application, a phone system’s admin interface, an automation tool, a feed reader, a security dashboard, and a messaging bridge. Between them they offer local accounts, an admin password in a config file, or nothing at all.
For those, the identity provider works as a gatekeeper instead: a proxy that sits in front of the application and refuses to pass a request through until the user has authenticated. The application is not modified and does not know it is happening.
That capability decides the choice, because the alternative is not “use a different identity provider”. The alternative is a lab where half the services are covered by single sign-on and the other half have their own passwords, which means multi-factor authentication is enforced on the half that needed it least. Self-hosted applications are exactly the population most likely to have weak authentication and least likely to have SSO support, and those two facts are correlated in the wrong direction.
Enforcing MFA at the identity layer rather than per application follows from the same reasoning. It only means something if the identity layer is actually in the path for everything.
How it is actually used here
Live on its own virtual machine, behind a reverse proxy, with both access paths proven rather than assumed. Nightly database backups run with three guards, and each guard was deliberately triggered before being trusted, on the principle that a guard is not a guard until it has been seen to stop something.
It was deployed at current stable, not the version the runbook pins, which is roughly twenty months old.
That was not a fresh decision so much as an unapplied one. An earlier review found the project’s version-pinning method inverted: it had been pinning to the oldest release that fixed all known vulnerabilities, which sounds conservative and is the opposite. A version chosen as the oldest one that fixes today’s known problems is guaranteed to ship every problem found after it. The method was corrected to pin to current stable and treat published vulnerability lists as a rejection floor rather than a selection criterion. That correction reached several documents and never reached this one.
The human confirmed the current-stable deployment rather than rolling back, and the timing was the substance of that call: the database was minutes old and held no users, no applications and no enrolled devices, so reversing was nearly free. The moment anything enrolls against an identity provider, changing its version downward stops being a configuration change and becomes a schema rollback. Deciding to keep it closed a window that was about to close on its own terms.
The two ways a service gets connected
OIDC, for applications that support it. The application is registered with the identity provider, receives a client ID and secret, and redirects users there to log in. The application still has its own notion of a user account, but it stops storing a password and starts trusting an assertion.
Proxy and forward authentication, for applications that do not. The reverse proxy asks the identity provider whether the current request is authenticated before forwarding it. If not, the user is sent to log in and returned afterwards. The application receives a request that has already passed authentication and needs no awareness of any of it.
The practical difference is what the application knows about the user. Forward authentication gives you a wall in front of a door. It does not give the application a user identity to make its own decisions with, so a service protected this way is generally all-or-nothing per user, and finer-grained permissions have to be handled by group membership on the gate rather than inside the application.
What it cost
It is a single point of failure, by design. If the identity provider is down, everything behind it is inaccessible, including services that are themselves perfectly healthy. That is not a defect in the software, it is what consolidating authentication means, and pretending otherwise would be dishonest. It moves an availability requirement onto one machine, which is why it gets its own virtual machine and nightly backups rather than sharing space with something else.
It constrains the build order permanently. The rule the runbooks state as a hard requirement is that identity comes before services, and the reason is sequencing rather than security: bolting authentication onto a running service that already has users and data in it is far more work than configuring it on day one, and the version bolted on afterwards is usually worse. That rule has now shaped the order of the entire build.
Running current stable means the documentation ages against a moving target. Current Authentik does not use Redis, which older versions did. Three of the lab’s own documents still describe a Redis dependency and a directory for it, because they were written when that was true. Nothing is broken, and the discrepancy was found by checking the shipped image’s own configuration rather than the project’s documentation. It is a small, honest tax: choosing current stable over a pin means your own writing about it goes stale in ways a frozen version would not.
It is not a lightweight service. It carries a database and a worker process alongside the web application, and it is one of the larger resource reservations in the design. Authelia would have been meaningfully smaller. That was the trade accepted in exchange for the outpost capability.
What would change the decision
As with the other component notes so far, these are the agent’s reasoning from the record rather than the human’s stated position.
- If the estate stopped needing the proxy. The outpost capability is the whole argument. In a lab where every service spoke OIDC natively, a lighter identity provider would win on resource cost alone.
- If the project’s licensing split moved. Features that are open today moving behind a commercial tier would not break anything already running, and it would change what the next five years look like, which is the horizon this lab plans against.
About Authentik
Authentik is an open source identity provider, developed by Authentik Security Inc. and a community of contributors. It implements the common federation protocols, including OIDC, OAuth2, SAML and LDAP, and provides multi-factor authentication, group-based access control and user lifecycle management. Its distinguishing feature among self-hosted options is a proxy mode that can place authentication in front of applications with no native support for it.
It is deployed as a set of containers, and offers both a free open source edition and a paid enterprise edition.
- Website — goauthentik.io
- Documentation — docs.goauthentik.io
- Source — github.com/goauthentik/authentik
- Community — GitHub discussions