!!! Overview
[{$pagename}] are and Italian cookie.


and also

[{$pagename}] are [authorization] [credentials] that provide flexible support for controlled sharing in decentralized, [Distributed systems]. 
[{$pagename}] 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])

[{$pagename}]s are improvements on traditional [cookies] that reduce the [scope|OAuth Scopes] or capability of a given [token] or allow for more distributed capabilities. [{$pagename}] 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, [{$pagename}]-based tokens can be verified [cryptographically|Cryptography] away from the [issuer], using standard libraries and can replace regular [access_tokens]. 

!! [Access_tokens] and [Refresh_tokens] 
Traditional [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.

!! [{$pagename}] are More Secure
[{$pagename}] 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 [{$pagename}] [access_token] before sending it to an API. Additionally, you can [bind|Binding] it to a [TLS] [client] [certificate] before use. And it is possible to create as many [{$pagename}]s as needed from the single [access_token], and the scope of each can be restricted by the trusted client using a caveat.

!! Distributed [Access]
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, [Authorization Server], issues one access token wrapped in a [{$pagename}], which has a broad scope. As many [{$pagename}]s 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 [{$pagename}]s 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] 
[{$pagename}] continuously authorize that the user is who they say they are and that no one is [impersonating|Impersonation] 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]. 

[{$pagename}]s 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.



!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Authorize Anyone, Anything with Macaroons|https://www.forgerock.com/blog/cloud-series-authorize-anyone-anything-macaroons|target='_blank'] - based on information obtained 2020-05-10 
* [#2] - [Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud|https://research.google/pubs/pub41892/|target='_blank'] - based on information obtained 2020-05-10 
* [#3] - [Macaroon|Wikipedia:Macaroon|target='_blank'] - based on information obtained 2020-05-10