Three questions people treat as one
A Socratic walk-through of three questions people treat as one — reasoned out one step at a time, not lectured.
The question we started with
THE QUESTION #Why are 'who are you', 'prove it', and 'may you' three separate problems?
"The user is logged in" is treated as a single fact that settles everything. But listen to what a system actually needs to establish before it acts: which account is this, is the person really that account, and is that account allowed to do this particular thing.
Those sound like one thought said three ways. Try answering any one of them without the others, though, and they come apart — and most of the awkward security failures in ordinary applications live in the seams between them.
Reasoning it through
REASONING #Take the first: who are you? This is only a claim — a username typed, a certificate presented, an identifier supplied. It costs nothing and proves nothing. Its whole job is to name which stored record we are about to reason over. What makes it hard is not security but stability: the identifier has to survive the person changing their email, their name, and their employer, and it must never be reassigned to someone else. This is why identity protocols keep a machine-generated subject identifier separate from anything human-readable, and why OpenID Connect explicitly warns against keying an account on the email address — addresses change hands.
Now the second: prove it. Here evidence enters. Something known, something held, something measured — and crucially, a moment in time. Ask what an authentication actually produces and the answer is small: a statement that at time T, evidence sufficient under some policy was presented for identifier X. That is all. It says nothing about what X may do, and it does not stay true; it decays. Which is why the interesting design questions are how long the resulting session should stand for that moment, and what should force a fresh proof — a sensitive action, a new device, elapsed time.
The third: may you? Notice how differently this behaves. Identity is one fact per person, but permission is a fact per person per action per object per moment. Alice may read this document today and not tomorrow, because the document moved, or her role ended, or the request came from an unexpected place. It is evaluated continuously, and it depends on things authentication never examined.
That is the argument for separation, and it is not tidiness. The three have different lifetimes — an identifier is permanent, a proof is momentary, a permission is revocable — and different owners. HR knows who exists; a security team owns how proof is demanded; the application team knows what its objects mean and who should touch them. Fuse them and each change drags the other two along.
The classic collapse is worth naming precisely, because it is so common. OAuth 2.0 is a delegation protocol: it answers "may this application act on this resource on someone's behalf". It was widely misused as a login mechanism, and the reasoning failure is exact — an access token proves that somebody once consented to grant an application access, not that the person in front of you now is that somebody. OpenID Connect was layered on top precisely to add the missing answer, in the form of an identity token that says who was authenticated, when, and how.
And there is a fourth thing hiding behind all three, which the tags for this topic call lifecycle. Every answer above assumes the identifier still refers to someone who should exist. Joiners, movers and leavers change that. An account whose human left the organization months ago will still authenticate perfectly and still pass every permission check that was granted to it — because nothing in the three questions asks whether the record should still be there.
The analogy
THE ANALOGY #Think of arriving at a conference. You say your name at the desk — that is a claim, and anybody could make it. You hand over a passport, and the clerk decides your evidence is good enough for the value of what is behind the door. You get a badge with coloured stripes, and every room you approach is guarded by someone who reads the stripes, not the passport, and who has been told this morning which stripes open which doors.
the badge stays in your hand, so the analogy makes possession look like proof, whereas the truly hard part in software is that a session token can be copied and used by someone who never presented the passport — which is why the badge check has to be re-derived from something bound to you, not merely held.
Clarifying the model
THE MODEL #The refinement that pulls it together: each question hands the next one an input, and only that input. Identification yields a stable subject identifier. Authentication yields an assertion about that identifier at a moment. Authorization consumes that assertion plus the resource and the action, and yields a yes or no. When a system is confusing to reason about, it is usually because a stage reached past its input — an authorization check that re-parses a token to work out who the user is, or a login flow that quietly decides what the user can do.
The misconception to correct is that a role granted at login settles the third question. Roles are an input to authorization, not a substitute for it. The decision still needs the object — "editor" says nothing about whether this document belongs to a project she left — and it still needs to be made now rather than remembered from an hour ago.
One honest complication: the separation is clean conceptually and leaky in practice, because tokens carry claims. Putting permissions inside a token makes checks cheap and makes revocation slow, since the token remains valid until it expires. That trade — fast decisions versus prompt withdrawal — is real, and short lifetimes are the usual compromise rather than a solution.
A picture of it
THE PICTURE #How to readRead each box as a separate concern with its own attributes and its own single operation, and read the arrows as the only thing each concern hands to the next. Identification passes a name and nothing more; authentication passes an assertion about that name at a moment, not a set of permissions; authorization adds the action and the object, which neither of the others ever saw. The lifecycle box points at two of them because it is the concern that keeps the whole chain honest — without it, a retired person's identifier still authenticates and still carries grants.
What became clearer
WHAT CLEARED #The three questions differ in what they range over: one fact per person, one moment per proof, and one decision per action on one object. Because those have different lifetimes and different owners, answering them in one step means every change to any of them disturbs the others. And the chain is only as trustworthy as the lifecycle process behind it, which is the question none of the three thinks to ask.
Where to go next
ONWARD #- How an identity token differs from an access token in practice, and what goes wrong when an application validates the wrong one.
- Why permission decisions that read the object at request time resist the stale-role problem that role checks at login cannot.
Key terms
TERMS #| Term | What it means |
|---|---|
| Identification | supplying an identifier that names an account, with no evidence attached. |
| Authentication | establishing, with evidence, that a party is the holder of that identifier, as of a particular moment. |
| Authorization | deciding whether a given actor may perform a given action on a given resource, now. |
| OpenID Connect | the identity layer added over OAuth 2.0 to supply the authentication answer that a delegation protocol does not. |
Every term the collection defines is gathered in the glossary.