Identity, authentication, authorization, and recovery

Four jobs that get collapsed into “login”

Identity is the record Riverstone uses for a person or workload: driver Kim Park, dispatcher Priya Shah, the YardOS service account. Authentication is the proof offered for that record: a password, a passkey, a one-time code, a hardware key, a workload certificate. Authorization is the decision about what that identity may do after proof succeeds: view this trailer, edit this dock assignment, export this customer list. Recovery is how the organization restores access when the authenticator is lost, without quietly creating a weaker front door.

NIST’s Digital Identity Guidelines (SP 800-63-4) separate these concerns because a strong authenticator attached to a shared mailbox is still a weak identity. NIST SP 800-207’s zero trust discussion likewise treats authentication and authorization as ongoing decisions, not a one-time castle gate. You can remember the split with a loading-dock metaphor: identity is the badge record, authentication is checking the badge, authorization is which doors the badge opens, and recovery is what happens when the badge is left in a taxi.

Worked login: FleetLink on a driver’s phone

Kim opens FleetLink. The app redirects to Riverstone’s identity provider. Kim enters a password and a phone prompt: that is authentication. The identity provider issues a session token bound to Kim. FleetLink then asks an access service whether Kim may see trailer 99. Dispatchers see every trailer; drivers see assigned routes only. If the token is valid but Kim is not assigned trailer 99, the application programming interface (API) must refuse. That refusal is authorization working. A Transport Layer Security (TLS) session and a green padlock do not replace it.

If IT later finds a login log that says “Kim Park authenticated from a new device,” that is not the same as “Kim Park moved trailer 99.” Authentication evidence is not authorization evidence and is not proof of physical presence. If the phone prompt was approved because Kim’s nephew likes tapping Allow, you have an authentication weakness that looks like a successful login in the security information and event management (SIEM) platform.

• Identity: who or what the account represents, including humans and services.
• Authentication: proof offered now, including phishing resistance and device binding.
• Authorization: permitted actions on named objects, preferably least privilege.
• Recovery: help-desk resets, backup codes, and device replacement can become the real authenticator.

Recovery and shared accounts undo the front door

The warehouse still keeps a shared login on a clipboard “in case YardOS locks someone out.” Logs may accurately identify that shared account but cannot reliably attribute its actions to Priya or a contractor. A help-desk reset that accepts a staff photo sent over chat may be easier to abuse than the passkey you just rolled out. Design recovery with the same seriousness as login: verify the person out of band, time-limit temporary passwords, and record who approved the reset.

When you write an access policy, name the identity, the authenticator expectations, the authorized actions, and the recovery path. If any of the four is “we will figure it out,” attackers will figure it out first. Later SOC lessons will ask you to triage a login alert; they only work if these records exist.