Overview#Macaroons are and Italian cookie.
Macaroons are authorization credentials that provide flexible support for controlled sharing in decentralized, Distributed systems. Macaroons are widely applicable since they are a form of bearer credentials—much like commonly-used cookies on the Web—and have an efficient construction based on Keyed-Hash Message Authentication Code (HMAC)
Macaroonss are improvements on traditional cookies that reduce the scope or capability of a given token or allow for more distributed capabilities. Macaroons offer a new type of token format, specifically used with OAuth 2.0/OIDC scopes, and they are available in the Identity Cloud.
In traditional token-based authentication, Access Tokens represent the authorization of a specific application to access specific parts of a user’s data. They are kept confidential with only the application itself, the Authorization Server, and Resource Server ever seeing the token. To allow for a new set of use cases to be focused on distributed capabilities, Macaroons-based tokens can be verified cryptographically away from the issuer, using standard libraries and can replace regular access_tokens.Access_tokens are short-lived because, if leaked, they allow potentially Malicious users access to the resource-owner resources. However, clients may need to access the protected data for periods of time that exceed the Access_token lifetime or when the Resource Owner is not available. In some cases, it is unreasonable to ask for the Resource Owner's consent several times during the same operation.
Refresh_tokens solve this problem. They are long-lived by default and allow you to configure the lifetime of the tokens in the OpenID Connect Provider settings, or in each client. Refresh_tokens, as opposed to Access_tokens, allow the OAuth Clients to ask for a new access_token without further interaction from the Resource Owner. However, refresh_tokens can only be used once.
Macaroons are More Secure#Macaroons are a new type of Bearer Token that can be used when issuing OAuth 2.0 Access_token and refresh_tokens. They allow caveats to be appended to restrict or to provide context for how a token can be used. They can also provide additional security, as these tokens can be restricted temporarily.
For example, you can add a 5-second expiration time to a Macaroons access_token before sending it to an API. Additionally, you can bind it to a TLS client certificate before use. And it is possible to create as many Macaroonss as needed from the single access_token, and the scope of each can be restricted by the trusted client using a caveat.access_token with multiple clients and resource servers, without compromising on security. Rather than issuing multiple access_tokens with different scopes, Authorization Server, issues one access token wrapped in a Macaroons, which has a broad scope. As many Macaroonss as needed can be created from the single access token, and the scope of each can be restricted by the trusted client using a caveat.
Caveats further add the ability for clients to restrict how the macaroon token can be used. The ability to add caveats make Macaroonss very useful for delegation, for example in a Microservice architecture. The client can delegate to other services, with a limited set of capabilities, bound by certain restrictions. For example, the client can append a token with a caveat that shortens the expiry time, or reduces the scope of the token, after it has been issued. Let’s say a user has an account receive and account payable with a bank. You can caveat the token with a macaroon so that the user cannot perform both actions on the same account within a 5 minute time window.
Continuous Authorization #Macaroons continuously authorize that the user is who they say they are and that no one is impersonating them via contextual authorization. They do this by using a Keyed-Hash Message Authentication Code (HMAC), a mechanism for calculating a Message Authentication Code that includes a Hash Function.
Macaroonss can be used when issuing OAuth 2.0 access and refresh tokens. They allow you to authorize resource access using bearer tokens that can be appended with caveats. They are based on a construction that is highly efficient, easy to deploy, and widely applicable.