How to revoke a token

Revocation identifiers

Biscuit tokens are bearer tokens. Revoking bearer tokens is usually done through revocation lists: a list of tokens that are no longer accepted is shared with all verifying parties. When authorizing a biscuit token, the library will make sure the token has not been revoked.

Such a mechanism relies on being able to uniquely identify tokens: we want to be able to revoke only the tokens that are not valid anymore, without revoking other tokens (even tokens with the same payload but have been issued to another holder). With offline attenuation, biscuits introduce another constraint: revoking a token should also revoke all derived tokens (else it would be trivial to circument revocation).

The biscuit spec (and libraries) provide you with:

  • a way to uniquely identify tokens (two biscuits with the same payload and secret key will be different)
  • a way to identify groups of tokens derived from the same parent token
  • a way to reject tokens based on their ids during authorization

The biscuit spec does not mandate how to publish revoked ids within your system; that depends a lot on the architecture and constraints of the systems. You can start simple with static revocation lists read through environment variables, and migrate to more complex systems as needed.

Listing revocation ids for a token

The CLI can be used to inspect revocation ids:

āÆ biscuit inspect test9_expired_token.bc --raw-input
Authority block:
== Datalog ==

== Revocation id ==


Block nĀ°1:
== Datalog ==
check if resource("file1");
check if time($date), $date <= 2018-12-20T00:00:00+00:00;

== Revocation id ==


šŸ™ˆ Public key check skipped šŸ”‘
šŸ™ˆ Datalog check skipped šŸ›”ļø

Providing a revocation list during biscuit authorization

In haskell

Rejecting revoked ids in haskell