Auth MechanicsAUTHENTICATION & AUTHORIZATION, FROM THE WIRE UP.
LESSON 38 OF 40

Add restrictions before delegating a Biscuit token.

A Biscuit holder can create a more restricted token without contacting the issuer. A receiving application programming interface (API) must verify the token chain and every restriction before allowing access.

Why this lesson?

A service gives a worker one task: read an approved quote before a deadline. The worker gets a token restricted to that document and time.

Learning goal and prerequisites
ONE NEW IDEA A Biscuit holder can create a more restricted token without contacting the issuer. A receiving application programming interface (API) must verify the token chain and every restriction before allowing access.
Review the previous lesson if any of these terms are new. The link below opens that lesson.
Request sequence Authorization sequence
STEP 01

Obtain the original token

A trusted issuer checks its policy and issues a token allowing document reads. This issuance endpoint is specific to the example application. It is not a standard OAuth endpoint.

Inspect request, response, and claims
Traffic inspector Examples only · not real requests
Try a failure scenario

↳ Change a condition

Read the detailed explanation
Key explanation

Why it exists, how it works, and where it fits

Delegated systems are safer when authority becomes narrower as it moves downstream. A service may need to let a worker read one document for a few minutes without giving that worker every permission the service itself holds. Biscuit tokens are capability tokens designed for that kind of restriction.

An issuer creates the original token with some authority. A holder can then attenuate the token by adding new restrictions, such as one resource, one action, or an earlier expiration time. The holder can add limits without contacting the issuer, but cannot remove limits that are already part of the token.

The receiving service verifies the token’s cryptographic chain and evaluates every restriction along with its own local authorization policy. A child token cannot become more powerful than the parent token from which it was derived.

This is useful in delegated workflows because each component can pass only the authority the next component needs. Biscuit does not make every API understand the token automatically, and it does not replace secure transport or application policy. The receiving service must be designed to trust the issuer and correctly enforce the token’s restrictions.

Check your understanding
Lesson checkpoint

Pass the lesson quiz

Answer every question correctly to unlock the next lesson. Retry as often as you need.

Glossary Definitions of technical terms