delegated, decentralized, capabilities based authorization token
Go to file
Geoffroy Couprie 09a8b33df9 update samples to reflect recent changes:
- context field in blocks
- verifier caveat errors so not have a block id anymore
- now a fact from one block can be used by another block
- FailedBLockCaveat error now applies to the authority block as well
- the authority block can contain facts without the authority tag (other
block still cannot contain facts with the authority tag)
- token pretty printing changes
2019-12-19 14:48:40 +01:00
assets add a logo 2019-01-07 12:19:08 +01:00
experimentations fix test code 2019-09-17 14:55:43 +02:00
samples update samples to reflect recent changes: 2019-12-19 14:48:40 +01:00
DESIGN.md mention regular expression string constraints 2019-12-19 09:51:14 +01:00
LICENSE add a license 2019-10-28 11:33:30 +01:00
README.md update the readme 2019-12-19 11:21:44 +01:00
schema.proto update the schema 2019-11-25 11:04:08 +01:00
SPECIFICATIONS.md text format 2019-12-19 11:07:43 +01:00

Biscuit authentication token

Join the chat at https://gitter.im/CleverCloud/biscuit

Goals

Biscuit is a (in development) authentication token for microservices architectures with the following properties:

  • distributed authorization: any node could validate the token only with public information;
  • offline delegation: a new, valid token can be created from another one by attenuating its rights, by its holder, without communicating with anyone;
  • capabilities based: authorization in microservices should be tied to rights related to the request, instead of relying to an identity that might not make sense to the verifier;
  • flexible rights managements: the token uses a logic language to specify attenuation and add bounds on ambient data;
  • small enough to fit anywhere (cookies, etc).

Non goals

  • This is not a new authentication protocol. Biscuit tokens can be used as opaque tokens delivered by other systems such as OAuth.
  • Revocation: while tokens come with expiration dates and revocation ids, revocation still requires external state management that we will not specify.

Roadmap

You can follow the next steps on the roadmap.

Current status:

  • the credential language, cryptographic primitives and serialization format are done
  • we have implementations in Rust, Java and Web Assembly (based on the Rust version)
  • Currently deploying to real world use cases such as Apache Pulsar
  • looking for an audit of the token's design, cryptographic primitives and implementations

How to help us?

  • provide use cases that we can test the token on (some specific kind of caveats, auth delegation, etc)
  • cryptographic design audit: we need to decide on a cryptographic scheme that will be strong enough

Project organisation

  • DESIGN.md holds the current ideas about what Biscuit should be
  • SPECIFICATIONS.md is the in progress description of Biscuit, its format and behaviour
  • experimentations/ holds code examples for the crypographic schemes and caveat language. code/biscuit-poc/ contains an experimental version of Biscuit, built to explore API issues

License

Licensed under Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)

logo by Mathias Adam

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be licensed as above, without any additional terms or conditions.