This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Macaroons...nobody
Macaroons

Version management

Difference between version and

At line 1 added 55 lines
!!! 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
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop