Cloud Series: Authorize Anyone, Anything with Macaroons
What are Macaroons?
Macaroons are access tokens that use contextual authorization to confirm that the user is who they say they are, and that no one is impersonating them. Developed by Google, Macaroons 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 OAuth2/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, macaroon-based tokens can be verified cryptographically away from the issuer, using standard libraries and can replace regular access tokens.
Access and Refresh Tokens
Traditional access tokens are short-lived because, if leaked, they grant 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 OAuth 2.0 Provider settings, or in each client. Refresh tokens, as opposed to Access tokens, allow the 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 a new type of bearer token that can be used when issuing OAuth 2.0 access 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 macaroon 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 macaroons as needed from the single access token, and the scope of each can be restricted by the trusted client using a caveat.
Macaroons can also be used in place of regular access tokens, as they allow the sharing of the single access token with multiple clients and resource servers, without compromising on security. Rather than issuing multiple access tokens with different scopes, ForgeRock, acting as the authorization server, issues one access token wrapped in a macaroon, which has a broad scope. As many macaroons 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 macaroons 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.
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 hash-based message authentication code (HMAC), a mechanism for calculating a message authentication code that includes a hash function.
Macaroons 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.