CONCEPT Cited by 1 source
Third-party caveat¶
A third-party caveat is a Macaroon caveat that says "this token is only valid if accompanied by a discharge token from authority X." It lets a token issuer delegate a sub-decision (typically authentication) to a separate authority, without that authority having to co-sign the main token.
How it's used at Fly.io¶
Fly.io uses third-party caveats for the canonical authZ / authN split (concepts/authorization-vs-authentication-token):
"Your main Fly.io Macaroon will have a caveat saying 'this token is only valid if accompanied by the discharge token for a user in your organization from our authentication system'. Our authentication system does the login dance and issues those discharges." (Source: sources/2025-03-27-flyio-operationalizing-macaroons.)
And for privilege separation of service tokens — Pet Semetary secret-reads require proving you have org permissions via a Macaroon before the read-secret token's third-party caveat discharges.
Mechanics (informal)¶
The permissions-token holder embeds a caveat containing: (a) the authority's identifier, (b) a challenge the authority must bind a discharge to. At verification time, the caller presents both the permissions token and a discharge token from the named authority covering the same challenge. Neither token alone grants access.
Architectural value¶
- Privilege separation. The two halves of authorization can be stored and transmitted separately; losing one doesn't grant use.
- Late-binding authentication. The auth authority can go offline without breaking already-discharged sessions.
- Service-token hardening. A third-party caveat can also
be stripped by an authority with access to the token
secrets (Fly's
tkdbstrip API), producing a token that only the already- authenticated holder can obtain.
Seen in¶
- sources/2025-03-27-flyio-operationalizing-macaroons — canonical instance covering both the user-token authN split and the Pet Semetary secret-read gating.