One login instead of twelve
Self-hosted identity, and why the boring option is the right one.
Count the places a person’s account exists at your organisation. The wiki. The monitoring dashboard. The git server. The registry. The ticket system. The VPN. Each one with its own password, its own idea of who is an admin, and its own list that nobody has audited.
Now imagine someone leaves. What is the procedure? If the honest answer involves a checklist and a search, the accounts you forget will outlive the employment. That is not a hypothetical risk, it is the normal outcome, and it is the actual argument for running an identity provider. Not convenience. Offboarding.
What it changes
With a central identity provider, services stop having users. They have sessions, handed to them by something else that did the authenticating.
A person exists in one place. Disable them there and every service goes dark at once, with no list to work through. Group membership becomes the thing that grants access, so “who can reach production” is a question with an answer rather than an investigation.
Second-factor enforcement becomes a single policy instead of twelve separate features of varying quality — half of which do not have it at all.
And people stop reusing one password across a dozen internal tools, because there is one password.
The protocol, in one paragraph
OIDC is the layer worth learning. A user hits a service, the service redirects them to the identity provider, they authenticate there, and come back with a signed token asserting who they are. The service validates the signature and trusts the claim. It never sees the password. It does not store credentials, cannot leak them, and has no opinion about password policy — that all lives in one place, maintained by people who thought about it.
The important consequence: your services stop being credential stores. Most internal tools have unremarkable auth code written once and never revisited. Deleting all of it and replacing it with “validate this token” is a large reduction in the amount of security code you are responsible for.
Modelling: keep it boring
The failure mode with an identity provider is over-modelling. It will happily support fine-grained roles, nested groups, attribute mapping and per-client scopes, and you can build something so expressive that nobody can answer “what can this person do”.
Start with groups that mirror how you actually talk about access. If the sentence people say is “the infrastructure team can get to the cluster”, make a group called that. Grant things to groups, never to individuals — an individual grant is invisible in every review and outlives the reason it was made.
Resist per-service roles until a service actually needs to distinguish two kinds of user. Most do not. Most need “may this person in, yes or no”, and modelling three tiers of permission for a dashboard that has one page is work you will maintain forever for no benefit.
Services that cannot speak OIDC
Some things cannot do modern auth. Old admin panels, appliances, dashboards with a single shared password. You will have several and they are usually the ones you most want behind authentication.
The pattern that solves this is a forward-auth proxy: the reverse proxy in front of the service asks an authentication service whether this request carries a valid session, and only passes it through if the answer is yes. The application behind it is untouched — it does not know authentication happened, and does not need to.
This is unreasonably useful. It puts real, group-controlled, second-factor-enforced authentication in front of software that has no concept of any of it, without modifying the software. A lot of “we cannot secure that, it is legacy” turns out to be false.
The caveat: the proxy is now load-bearing. A route that bypasses it — a second ingress, a port exposed directly, a health check path excluded a bit too generously — is a route with no authentication at all. Bypass paths deserve the same scrutiny as firewall rules.
What it costs
It becomes a dependency of everything. When identity is down, nothing is reachable — not because those services are broken, but because nobody can prove who they are. That is a real concentration of risk and you should be honest about it rather than discovering it during an incident.
Which means: it needs to be genuinely reliable, it needs monitoring that checks the login flow end to end rather than just whether the process is running, and you need a documented way in when it is down. Break-glass access that does not depend on the thing that is broken. Written down, stored somewhere reachable without a login, and tested — an emergency procedure nobody has ever run is a procedure that does not work.
Sessions and tokens have subtle behaviour. Token lifetime, refresh, and what actually happens when you disable an account mid-session are worth understanding properly. Disabling a user does not always terminate their existing sessions immediately, and if your mental model is “I clicked disable, they are out”, you may be wrong for the length of a token lifetime. Find out which, before you need to rely on it.
Upgrades are real work. It sits in front of everything, so testing an upgrade means testing every login path. This is the price of centralising, and it is worth paying, but it should be planned rather than done casually on a Friday.
Would I do it again
Immediately. Not for single sign-on, which is a pleasant side effect, but for the property that a person is one object and access is one decision.
The moment that justified it was the first time someone left and offboarding was: open one page, disable one account, done. No checklist. No wondering about the monitoring dashboard. Everything went dark at once, because everything had been asking the same question all along.
Everything else — the second factor, the audit log, the deleted auth code — is upside.