Identity goes deeper

You have carried two identity mechanisms since Modules 5 and 6, the cookie’s coat-check ticket and the bearer token. Now it is time to look at the machinery properly, since the differences decide real product behavior.

Sessions versus tokens

Sessions and tokens come down to one question. Where does the truth live?

A sessionConcept · lights on your mapsession mechanicsThe server keeps the memory (“ticket 8k2f = Erik”) and the cookie carries only the ticket. Revocation is instant because tearing up the ticket ends it, and the cost is that every check hits server state. keeps the truth server-side. The cookie in your browser is Module 5’s coat-check ticket, holding nothing but a number. The actual record of who is logged in stays behind the counter, on the server. Logout tears the ticket up, so revocation is instant and total.

A tokenConcept · lights on your maptoken mechanicsIdentity that needs no memory behind it. A server reads the claims, checks the signature, and trusts the result without asking anyone. Cheap at scale, and awkward to cancel early, which is why expiries stay short. inverts this. The credential itself carries signed claims, who you are and until when, and any service can verify the signature locally with no coat-check consulted.

Hear the Module 9 echo. Tokens are identity gone stateless, perfect for twelve interchangeable backend instances. The usual bill for statelessness comes attached, and a stolen token stays good until it expires.

So the standard defenses follow, short expiries plus extra machinery for the emergencies. That is the whole tradeoff. Sessions buy control and tokens buy scale.

What is single sign-on?

Now scale identity to a whole company, where one employee faces fifty apps. Does that mean fifty passwords?

The grown-up answer is single sign-onConcept · lights on your mapsingle sign-onSSO. Log in one time and carry that proof across every app at work, because the apps defer to a shared identity provider instead of keeping their own passwords. Fifty logins collapse into one, and so does offboarding. (SSO), which means authenticating once with a central identity provider so that every company app trusts its vouching. Okta and Google Workspace are the names you’ll meet.

It is Module 6’s “log in with Google,” wearing a badge, and it means one strong front door instead of fifty flimsy ones.

SSO is also the machinery last lesson’s offboarding finding was missing. When someone leaves, disabling one central account closes all fifty doors at once. Same-day revocation becomes a single action instead of a fifty-app scavenger hunt.

What is multi-factor authentication?

The front door itself gets reinforced with multi-factor authenticationConcept · lights on your mapmulti-factor authenticationMFA. Login demands two unrelated proofs, typically a memorized one plus a physical one, so a leaked credential by itself opens nothing. Security teams rank it among the highest-value upgrades in common use. (MFA), which requires a second kind of proof beyond the password.

The factors are different in kind, not just in number.

• Something you know, such as the password
• Something you have, such as a phone that gets the prompt or a hardware key
• Something you are, such as a fingerprint or face

Requiring the phone prompt as a second step turns a stolen password from a catastrophe into a routine alert. When security teams say MFA is non-negotiable, the arithmetic is simple. Passwords leak constantly, and possession doesn’t travel with them.

One caveat is real, though. A phishing site built to relay the login in real time can trick a user into approving the prompt too, and the attack has industrial tooling now. That is why the strictest setups issue hardware keys, which refuse to vouch for an impostor site at all. The trade calls this phishing-resistant MFA.

What is a service account?

One identity remains, and it is the one nobody thinks of. A service accountConcept · lights on your mapservice accountThe login that belongs to a program rather than a person. Pipelines, backup jobs, and services authenticate this way, and these accounts deserve tighter limits than human ones, since nobody feels it when one starts acting strangely. is an identity for software: the pipeline that deploys, the worker that drains the queue, the backup job that runs at 2am.

Each one holds credentials, holds roles, and deserves least privilege, exactly like a human, only more so. That is because no instinct flags a service account behaving oddly at 4am.

And here a Module 8 thread ties off. When the secrets manager hands credentials to an application at startup, these are the identities receiving them.

The mental model to remember

A session keeps the truth server-side, which gives instant revocation but means every check consults the coat-check. A token carries its own signed claims, verifiable anywhere but revocable before expiry only with extra machinery. Sessions buy control, and tokens buy scale.

SSO is one strong front door that every company app trusts, and one switch that cuts all access on departure day.

MFA demands a second kind of proof, so a stolen password alone stops working, and hardware keys resist even the phishing pages that relay prompts.

A service account is an identity for software, credentialed by the secrets manager, governed by least privilege, and watched more closely than humans, not less.

You should now be able to hear “we’re on SSO with MFA enforced, and services use short-lived tokens” and recognize it as a defensible identity design, described in one sentence.