All Projects → macaroon-rs → macaroon

macaroon-rs / macaroon

Licence: MIT license
Rust implementation of macaroons.

Programming Languages

rust
11053 projects

Projects that are alternatives of or similar to macaroon

firebase-spring-boot-rest-api-authentication
Firebase Spring Boot Rest API Authentication
Stars: ✭ 172 (+975%)
Mutual labels:  cookies, authorization
macaroons
An Erlang Macaroons library compatible with libmacaroons
Stars: ✭ 27 (+68.75%)
Mutual labels:  authorization, macaroons
XAF Security E4908
This repository contains examples for Role-based Access Control, Permission Management, and OData / Web / REST API Services for Entity Framework and XPO ORM
Stars: ✭ 47 (+193.75%)
Mutual labels:  authorization
Client-Storage
🗄 Bulletproof persistent Client storage, works with disabled Cookies and/or localStorage
Stars: ✭ 15 (-6.25%)
Mutual labels:  cookies
svg-to-swiftui-core
Headless package for converting SVG to SwiftUI
Stars: ✭ 25 (+56.25%)
Mutual labels:  cookies
hiba
HIBA is a system built on top of regular OpenSSH certificate-based authentication that allows to manage flexible authorization of principals on pools of target hosts without the need to push customized authorized_users files periodically.
Stars: ✭ 333 (+1981.25%)
Mutual labels:  authorization
auth
🔑 Laravel Authentication package with built-in two-factor (Authy) and social authentication (Socialite).
Stars: ✭ 39 (+143.75%)
Mutual labels:  authorization
rbac-tool
Rapid7 | insightCloudSec | Kubernetes RBAC Power Toys - Visualize, Analyze, Generate & Query
Stars: ✭ 546 (+3312.5%)
Mutual labels:  authorization
spring-boot-login-example
Spring Boot Login and Registration example with MySQL, JWT, Rest Api - Spring Boot Spring Security Login example
Stars: ✭ 50 (+212.5%)
Mutual labels:  authorization
nexus3-github-oauth-plugin
This nexus plugin provides a way to authenticate/authorize your users based on Github.
Stars: ✭ 52 (+225%)
Mutual labels:  authorization
react-jwt-auth
React JWT Authentication & Authorization example - React.js Login and Registration example
Stars: ✭ 307 (+1818.75%)
Mutual labels:  authorization
Meteor-Cookies
🍪 Isomorphic bulletproof cookie functions for client and server
Stars: ✭ 41 (+156.25%)
Mutual labels:  cookies
caddy-security
🔐 Authentication, Authorization, and Accounting (AAA) App and Plugin for Caddy v2. 💎 Implements Form-Based, Basic, Local, LDAP, OpenID Connect, OAuth 2.0 (Github, Google, Facebook, Okta, etc.), SAML Authentication. MFA/2FA with App Authenticators and Yubico. 💎 Authorization with JWT/PASETO tokens. 🔐
Stars: ✭ 696 (+4250%)
Mutual labels:  authorization
raider
OWASP Raider: a novel framework for manipulating the HTTP processes of persistent sessions
Stars: ✭ 88 (+450%)
Mutual labels:  authorization
flagCookies
A cookie manager, browser add-on to manage and flag cookies. On stereoids.
Stars: ✭ 42 (+162.5%)
Mutual labels:  cookies
deflek
index and API RBAC for Elasticsearch and Kibana via reverse proxy. DEPRECATED
Stars: ✭ 13 (-18.75%)
Mutual labels:  authorization
spring-boot-jwt-auth
🔑 Sample Spring boot application secured using JWT auth in custom header(X-Auth-Token).
Stars: ✭ 57 (+256.25%)
Mutual labels:  authorization
local-storage-fallback
Check and use appropriate storage adapter for browser (localStorage, sessionStorage, cookies, memory)
Stars: ✭ 103 (+543.75%)
Mutual labels:  cookies
hapi-doorkeeper
User authentication for web servers
Stars: ✭ 14 (-12.5%)
Mutual labels:  authorization
aiohttp-login
Registration and authorization (including social) for aiohttp apps.
Stars: ✭ 53 (+231.25%)
Mutual labels:  authorization

Ferris holding French macaroons

macaroon

Rust implementation of macaroons.

Crates.io Build Status codecov Docs.rs

NOTE: THIS LIBRARY SHOULD NOT BE CONSIDERED SECURE AND HENCE SHOULD NOT BE USED IN PRODUCTION UNTIL IT PASSES A FULL SECURITY AUDIT. THE API IS ALSO LIKELY TO HAVE BREAKING CHANGES BETWEEN 0.X MINOR VERSIONS AND SHOULD THEREFORE NOT BE CONSIDERED STABLE.

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)

Examples

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 = MacaroonKey::generate(b"key");

// 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 = MacaroonKey::generate(b"different key");

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()),
                                           &other_key,
                                           "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.

Minimum Supported Rust Version

This crate supports Rust Language 2021 Edition and currently commits to working with stable Rust version 1.56 and later. It requires std.

Going forward, it should support every stable version of Rust, and at any given time maintain compatibility with stable versions of Rust released in the past 6 months or so. In other words, it will not depend on language features or syntax just released as stable in the past 6 months.

Contributing

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

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].