CONCEPT Cited by 1 source
Authorization vs authentication token¶
Separating authorization (what the bearer may do) from authentication (who the bearer is) into two distinct tokens — instead of conflating them in one — is a security posture that narrows the blast radius of token theft.
Fly.io's explicit framing:
"Macaroons by themselves express authorization, not authentication. ... By requiring a separate token for authentication, we minimize the impact of having the permissions token stolen; you can't use it without authentication, so really it's just like a mobile signed IAM policy expression." (Source: sources/2025-03-27-flyio-operationalizing-macaroons.)
How Fly.io implements it¶
- The main user token is a Macaroon carrying a third-party caveat pointing at the authentication service.
- The auth service issues short-lived discharges for authenticated users.
- Operations require both tokens presented together — "neither half alone is sufficient."
- Service tokens are engineered differently:
tkdb's third-party-caveat-strip API produces an authZ-only Macaroon that the recipient further attenuates to bind to their environment.
Why it matters¶
- Theft of the authZ token alone is useless. Without a current discharge, the permissions cannot be exercised.
- Session bounds move to the auth service. Discharge expirations bound session lifetime without changing the permissions token.
- Service-token hardening is natural. You can give a long-lived authZ token to running code as long as you remove (strip) the authN caveat from it; further attenuation then binds it to a specific host/VM so theft from anywhere else is useless.
Seen in¶
- sources/2025-03-27-flyio-operationalizing-macaroons — canonical wiki instance of the split, both for user tokens and for the service-token engineering pattern around it.