Who is asking

Every request Case’s phone has sent this morning carried something this act has not mentioned yet: proof of who was asking.

Two questions hide in that sentence, and they are different questions. Who are you? And what are you allowed to do? Engineers keep them apart with a care that borders on ceremony, and the ceremony pays for itself every time something goes wrong.

Who are you

The first question is authenticationConcept · lights on your mapauthenticationVerifying who or what is making a request. Who are you? Engineers shorten it to authn. A separate question from authorization, with separate failures.. Case answered it weeks ago, once, on a quiet evening: loginConcept · lights on your maploginThe moment a user proves who they are, by password, code, or a thumbprint, and receives something the device can present with later requests instead of proving it all over again. with a password and a code from a text message. What the phone received in exchange, and has carried ever since, is a tokenConcept · lights on your maptokenA value a client presents as evidence that it was granted particular access. It can stand for a user, a session, an application, or a set of permissions, and the server validates it before trusting anything it claims.: a sealed pass that rides along inside a header of every request. This morning’s parcel carried it. That is how POST /register knew which human it was registering.

Software gets identified too. When the timing vendor’s systems connect to Traversal, no person is present to type a password, so the vendor authenticates with an API keyConcept · lights on your mapAPI keyA secret value identifying and authenticating an application or account making API requests, usually naming the software rather than a person. Used for access, counting, rate limits, and billing, and protected like the password it effectively is.: a long secret naming the software itself.

What may you do

The second question is authorizationConcept · lights on your mapauthorizationDetermining what an already-identified requester is allowed to do. Engineers shorten it to authz, and it is answered after authentication, never instead of it.. The race director’s login opens the organizer portal; it does not open Finn’s dashboard. Case’s token can enter Case in the lottery; it cannot read anyone else’s entry. Knowing who you are and deciding what you may do are separate gates, in that order, and half of all security stories are about a door that checked only one.

Lending a key without handing it over

One more shape, and it is the subtlest in the scene. Case keeps a Ledgerline account, the way most runners do. This morning Traversal needs Ledgerline to charge it. Case would rather not hand Traversal the Ledgerline password, and the modern answer is OAuthConcept · lights on your mapOAuthA widely used standard letting one application act on your behalf at another service without ever receiving your password. You prove yourself to the provider directly, and the provider hands the application a token that is limited, expirable, and revocable.: Case says yes to Ledgerline directly, and Ledgerline hands Traversal a narrow token that can do one kind of thing and can be revoked with one tap. Traversal gets permission. It never gets the key.

Who you are, what you may do, and how to lend a key without losing it. The morning knows Case now. What it wants next is Case’s money.