The Door: Why Identity Is a Platform Capability, Not an Application Feature

Centralised identity is not a new idea, and it works. Most organisations already have it: one system that holds the list of people and checks their credentials when they sign in — a directory service, an identity platform, or whatever came with the suite they already pay for — with single sign-on in front of it, so that one login admits a person across most of what they use. Whichever you run, it is a respectable answer to "who are our people?" and a sensible default; nothing here asks you to throw it away.

What this series argues is narrower: owning that layer yourself is now possible. Not out of vendor defiance, but because the things that made it unreasonable have changed. Identity has standards that make it portable rather than proprietary; a managed relational database gives you a policy store with real constraints, transactions and revocation; serverless functions at the edge put the check where requests arrive instead of inside every application; and the tooling that writes and verifies software has made building and testing it far cheaper than five years ago. Owning your own authentication and authorization is no longer a question of capability — it is a question of design.

That is not the same as saying you should: buying remains the right default, and the decision — with its costs — is set out below. What the series offers is the other half: what it actually takes to own the door — the layer that decides who gets in. The components and flows, the order to build them in, how to keep every part replaceable by a standard rather than an SDK, how to operate it, and how to tell which layer refused you — written from a system we designed, built and run.

This first post is about why that layer is a platform capability rather than a feature of each application — and how to decide whether to buy it or build it. The three that follow are the architecture, the build and the operation; read together, they double as an audit of the system you already have. It starts with arithmetic.

The Arithmetic of Many Applications

Put two numbers next to each other: n applications and m people. Authentication became one system for those m people, once, and stayed that way. The rest of the access decision — who may do what, in which application, until when — was never centralised, so it is still made n times. That is the arithmetic worth doing.

The person's cost is the one we notice, because it shows up as a support ticket. The operator's cost is the one that hurts, because it grows with every hire. The auditor's cost is the one that ends conversations. "We think access was removed" is not an answer, and a credential nobody remembered to disable is not theoretical — it is the ordinary way access outlives the reason it was granted.

So the first thing a shared identity layer owes you is an audit trail: one record of who was given what, when, by whom, and until when. The second is that the record stays useful after access ends — which is what least privilege, the minimum a job needs for only as long as it needs it, turns from a slogan into a policy you can review.

None of this is an argument for centralisation as a virtue. It is an argument about duplication of a decision. A password check was the same decision in every application, which is why it was centralised once. A permission, a session and an access review are the same decision too — and they are still made n times. Making them n times does not make them n times safer; it makes them n times easier to get one wrong, and it puts each mistake somewhere nobody is looking.

What this shows: a common setup — central sign-in, one session and one authorization decision per application.

What this shows: the design this series describes — central sign-in too, one session shared by every application you build, authorization still per application.

Both ways are valid, and this series develops the second, the shared session, because the costs above come from per-application sessions and grant records, not sign-in, and one session is adoptable only for the applications you build. Software you do not control keeps its own session — for that, a subscription's single sign-on is right, and the same layer can later become its provider. Part 3 sets out the choice and its costs.

That session is shared by design — the same one for every application, which is what makes one sign-out end access everywhere. Sharing concentrates risk, and the design says so rather than hiding it: the session is unreadable by page scripts, HTTPS-only, restricted in cross-site use, short-lived and revocable. And authorization stays per application — a session that reaches an application still cannot do what that application's roles forbid.

Four Words That Are Not Synonyms

English hides four different jobs inside the single word auth. Separate them once and the rest of the series becomes legible — and notice which two the directory already does for you, and which two it never has.

Identity is the durable record of a person or a machine. It exists once and is referenced everywhere: not a password, not a session, just the fact that this person is known in the applications you run.

Authentication is proving who someone is, right now. It takes a credential — something the person knows, has, or is — and produces a statement that the proof succeeded. Notice what it does not produce: a permission. Authentication answers "who", and stops there.

Authorization is the decision about what a proven identity may do. It needs three things: the identity, the action, and the thing being acted on. It is a different system from authentication, with a different failure mode, and — the part that saves time in an incident — a different owner. The service that performs authentication has a name worth knowing: the identity provider.

Session is how the proof travels between requests, so the person is not asked to prove themselves again on every click. It is a transport decision: how long the proof lives, where it is accepted, and how it is ended early.

What this shows: four jobs in a line — and that each one produces something different: a record, a proof, a decision, a transport.

When these four live in one component, a single failure has one shape: "it doesn't work." When they are separate, failures become specific — and specificity is what makes a system operable. The clearest example is the pair of refusals every reader has met:

• "I don't know who you are." No credential arrived, or the one that did has expired or cannot be verified. The remedy is a sign-in.
• "I know exactly who you are, and this is not yours." The credential verified perfectly. What is missing is a grant. The remedy is access, not a login.

Those two situations are usually reported with the same words ("I'm getting a forbidden"), and they are handled by different people. A system that lets them be interchangeable has quietly made its own incidents harder to resolve.

What this shows: two different questions on the request path — and the two refusals people report with the same words.

What a Separate Layer Buys, and What It Costs

A dedicated identity layer moves those questions out of every application and into one place. What it buys is concrete: one credential per person instead of one per application; one place to grant, change and revoke; one access review that can actually be answered; and one session that admits many applications rather than a separate sign-in for each.

What it costs is concentration, and the cost is not rhetorical. The door you just built is now the most important component in the estate. When it is unavailable, everyone is locked out at once — which is a different failure from one application being down, and it deserves to be designed for, tested for, and staffed for. When its policy is wrong, it is wrong everywhere. Its mistakes now have the blast radius of the whole estate — the price of removing n smaller ones.

Two consequences follow, and they are why this series spends as much time on operation as on design. First, the layer must fail closed — refusing rather than admitting when it cannot decide — and it must also fail specifically: a reader whose access is refused should be able to tell whether to sign in again, request access, or call an engineer. Second, it must be legible: an access decision that cannot be traced back to the grant that produced it is not a decision, it is an opinion.

Designing the Door to Stay Open

Fail closed settles what the door does when it cannot decide. Availability settles how often that happens — and since everyone depends on it, availability belongs in the design from the start, not in an operations backlog. Three ideas carry most of it.

Keep the common check local. Verifying a session should need nothing more than the credential it carries and the issuer's published keys, both held in memory. The most frequent decision in the estate then keeps working while the policy store is slow or unreachable — and the store's availability matters only to the operations that genuinely need it.

Take the redundancy the platform gives you, and arrange the rest. Serverless functions at the edge already run in many places; what you arrange yourself is the store's replication and backups, and the signing keys. Publish them as a set, rotated with overlap, so sessions in flight stay verifiable while a new key takes over.

Degrade by decision, not by outage. When a dependency is unavailable, refuse the operations that need it and allow the ones that do not — with a short, explicit staleness bound on anything served from cache. "Everything is refused" and "everything is allowed" are both failures; the design should name which operations fail first, in the refusal itself.

Make the door visible while it is working. Noticing an outage is the easy half; seeing one coming is the half that saves you. A door that reports its own operation turns a future incident into a trend someone can act on. The signals are few — sessions verified, refusals issued and why, how long the policy store took, whether it fell back to cached keys — and that view belongs in the design, not in a dashboard added after the first bad night. Every application contributes the same few signals, so one panel can answer "is access working, for whom, and where is it degrading?" without anyone reading four systems' logs.

What this shows: which parts of the door keep working when a dependency is unavailable, and which do not — a map nobody should be discovering during an outage.

The test that keeps this honest is to exercise the degraded path, not only the refusal path: an untested degradation is not a design, it is a discovery — and the signal is what turns the next one into a warning.

There is one more cost, and it decides the build-or-subscribe question: a platform capability is not a feature you ship and move past. Someone must own it afterwards — its correctness, its running cost, and the day your access model changes.

Subscribe or Own: A Decision, Not an Ideology

The identity market is mature, and most organisations should use it. Part of what these services sell, you may already own: single sign-on against a corporate directory. The rest is the part this post is about — automatic provisioning and de-provisioning, multi-factor authentication, password resets and breach detection, authorization that fits your model, and audit artefacts a compliance auditor recognises. Not the least of what they sell is someone else's liability for a security-critical component.

The question is not whether those things are valuable. It is which of them you need, and which part of the problem is genuinely yours.

What a subscription does not fix. Every dependency has four faces worth naming before you sign. Commercial: price, packaging and the roadmap are decisions made by someone whose interests are not yours. Jurisdictional: your identity data lives where the provider chooses, under the law that reaches it. Operational: their outage is your outage — the door is the one component whose failure stops everything at once. Exit: leaving is a project with a budget, and it is cheap only if the integration is standards-shaped rather than SDK-shaped.

None of this is an argument to build: each is a question to ask before subscribing, and for most organisations the answer is still "subscribe". It is, though, why control belongs in the decision as a real column. The strongest reason to own the door is not that a vendor is bad; it is that the door is the one thing you must always be able to open. Part 3 puts a price on that with an exit drill.

The honest counter-list runs the other way — do not build it if you cannot staff it, cannot test it, or have not written down who may reach what. Access control is not a good place for a component that nobody owns after the sprint ends. If the answer to "who is on call for the door?" is silence, buy the door.

What this shows: the three questions that decide it, in the order that matters — need, capability, then fit.

Why We Built Ours

We chose to own it, and the reasons were specific rather than philosophical. Our access model is part of the product: grants are records about our resources — who, which role, on what, from when, until when, revocable — rather than a generic role list. That is exactly where subscription services are weakest and where per-identity pricing bites hardest, so it was the part worth owning. We also wanted the identity data under our own control. And we had the primitives to make ownership reasonable: a managed relational database for policy, with real constraints, transactions and revocation; and serverless functions at the network edge for the check. That last part matters — it puts the decision where requests actually arrive, instead of inside every application.

We are not claiming this is cheaper. Building is a commitment with a bill attached: we own a security-critical component, so we own its tests, its instrumentation and its on-call. One decision we would sequence differently, dated 2026-10-02: we shipped the door and its first operator application as one bundle, and separating them cost a week. What we claim is narrower: that we can explain every decision in it, and change any of it when our access model changes rather than when a vendor's roadmap allows.

Two things follow from owning it. The first is what the rest of this series does: explain every decision in it. The second is that this is also the work we do for other organisations. We write the map down because a reader can follow it with or without us — and because a design nobody can hand over is not finished.

That commitment only works if the design is disciplined, so the next three posts are about the architecture, the build, and how to operate it. A system that centralises the door for everyone must be built the way the rest of this blog argues software should be built: separated, contracted, idempotent (safe to re-run), traceable, and honest about where an abstraction earns its keep.

The Principles This Rests On

This series applies the principles argued in Why Software Design Principles Are What Make AI-Assisted Work Reliable, and an identity layer is the best place to see why they are load-bearing rather than ceremonial.

The last one matters most for the decision this post is about. Choosing to own your identity layer is only a real choice if the parts you did not build remain replaceable — otherwise the decision you make today is the decision you are stuck with. Part 3 describes that build.

The Orchestrator's Takeaway

• The problem is duplication, not login. Whether you buy the layer or build it, the decision it makes is currently made n times — and each copy is a chance to get it wrong where nobody is looking.
• Separate the four words before you separate the components. Identity, authentication, authorization and session fail differently and belong to different people; a system that blurs them turns every incident into a conversation about vocabulary.
• Centralising the door concentrates the risk. One place to revoke is also one place to be unavailable, which is why it must fail closed, fail specifically, and be traceable.
• Availability is part of the design, not the aftermath. Keep the common check local, take the redundancy the platform gives you, arrange the rest, and degrade by decision — then exercise the degraded path, because that is the day the door is judged.
• If you cannot see it, you cannot operate it. A door that reports its own traffic, refusals and dependency latency turns the next incident into a trend — and one panel across every application beats four sets of logs.
• Subscribe by default; own it deliberately. Buy it if you cannot staff it. Own it if the access model is genuinely yours — and only if the parts you did not build stay replaceable.