#cookies #authorization #credentials #macaroon


Fully functional implementation of macaroons in Rust

1 unstable release

Uses old Rust 2015

0.2.0 Sep 24, 2021
0.1.2 Sep 22, 2020
0.1.1 Feb 23, 2017
0.1.0 Feb 20, 2017

#504 in Cryptography

Download history 189/week @ 2022-06-04 294/week @ 2022-06-11 97/week @ 2022-06-18 186/week @ 2022-06-25 356/week @ 2022-07-02 18/week @ 2022-07-09 5/week @ 2022-07-16 88/week @ 2022-07-23 74/week @ 2022-07-30 145/week @ 2022-08-06 10/week @ 2022-08-13 15/week @ 2022-08-20 5/week @ 2022-08-27 20/week @ 2022-09-03 20/week @ 2022-09-10 104/week @ 2022-09-17

157 downloads per month

MIT license

1.5K SLoC

Ferris holding French macaroons


Rust implementation of macaroons.

Build Status codecov

NOTE: This project builds on previous work done by Deis Labs and the original libmacaroon-rs. We are currently working with getting in touch with the author and other interested parties to see if we can transfer the crate name to us as we are working on maintaining this. Large breaking changes have been made to the API of the macaroon crate. The full list of changes will be listed in the changelog once we release a new minor version for that same crate.

What are Macaroons?

Macaroons are bearer tokens (similar to cookies) which encode within them criteria within which the authorization is allowed to take place (referred to as "caveats"). For instance, authorization could be restricted to a particular user, account, time of day, really anything. These criteria can be either evaluated locally (a "first-party caveat"), or using special macaroons ("discharge macaroons") generated by a third party (a "third-party caveat").

A first-party caveat consists simply of a predicate which, when evaluated as true, authorizes the caveat. The predicate is a string which is either evaluated using strict string comparison (satisfy_exact), or interpreted using a provided function (satisfy_general).

A third-party caveat consists of a location string, an identifier, and a specially-generated signing key to authenticate the generated discharge macaroons. The key and identifier is passed to the third-party who generates the discharge macaroons. The receiver then binds each discharge macaroon to the original macaroon.

During verification of a third-party caveat, a discharge macaroon is found from those received whose identifier matches that of the caveat. The binding signature is verified, and the discharge macaroon's caveats are verified using the same process as the original macaroon.

The macaroon is considered authorized only if all its caveats are authorized by the above process.

Functionality Implemented

  • Creating macaroons, and adding first- and third-party caveats
  • Serialization - versions 1, 2 & 2J are supported
  • Validation (mostly for validating deserialized macaroons)
  • Creation of discharge macaroons
  • Verification of both first- and third-party caveats (the latter using discharge macaroons)


Until we release a new version and get the name in crates, you'll have to include this dependency like so in your Cargo.toml:

macaroon = { git = "https://github.com/macaroon-rs/macaroon", branch = "trunk" }


use macaroon::{Macaroon, Verifier, MacaroonKey};

// Initialize to make crypto primitives thread-safe
macaroon::initialize().unwrap(); // Force panic if initialization fails

// Create our key
let key = "key".into();

// Create our macaroon. A location is optional.
let mut macaroon = match Macaroon::create(Some("location".into()), &key, "id".into()) {
    Ok(macaroon) => macaroon,
    Err(error) => panic!("Error creating macaroon: {:?}", error),

// Add our first-party caveat. We say that only someone with account 12345678
// is authorized to access whatever the macaroon is protecting
// Note that we can add however many of these we want, with different predicates
macaroon.add_first_party_caveat("account = 12345678".into());

// Now we verify the macaroon
// First we create the verifier
let mut verifier = Verifier::default();

// We assert that the account number is "12345678"
verifier.satisfy_exact("account = 12345678".into());

// Now we verify the macaroon. It should return `Ok(true)` if the user is authorized
match verifier.verify(&macaroon, &key, Default::default()) {
    Ok(_) => println!("Macaroon verified!"),
    Err(error) => println!("Error validating macaroon: {:?}", error),

// Now, let's add a third-party caveat, which just says that we need our third party
// to authorize this for us as well.

// Create a key for the third party caveat
let other_key = "different key".into();

macaroon.add_third_party_caveat("https://auth.mybank", &other_key, "caveat id".into());

// When we're ready to verify a third-party caveat, we use the location
// (in this case, "https://auth.mybank") to retrieve the discharge macaroons we use to verify.
// These would be created by the third party like so:
let mut discharge = match Macaroon::create(Some("http://auth.mybank/".into()),
                                           "caveat id".into()) {
    Ok(discharge) => discharge,
    Err(error) => panic!("Error creating discharge macaroon: {:?}", error),
// And this is the criterion the third party requires for authorization
discharge.add_first_party_caveat("account = 12345678".into());

// Once we receive the discharge macaroon, we bind it to the original macaroon
macaroon.bind(&mut discharge);

// Then we can verify using the same verifier (which will verify both the existing
// first-party caveat and the third party one)
match verifier.verify(&macaroon, &key, vec![discharge]) {
    Ok(_) => println!("Macaroon verified!"),
    Err(error) => println!("Error validating macaroon: {:?}", error),

Backwards compatibility

As the original project is currently only released as a minor version, we expect to make breaking changes to the API, especially as we begin to use it in more real-world scenarios. However, all of these changes will be enumerated in each version's changelog and release notes. Once we have found an API that is sane and stable, we will release a 1.0, after which point, all versions of the 1.X line will be backwards compatible per semver.


We ❤️ any contributions. Any fixes to make things simpler or more idiomatic are also more than welcome. Please open a pull request if you have something you want to contribute. As the project matures, we will add a more detailed contributors guide


~95K SLoC