and also
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.
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.
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.
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.
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.