> On 13 Dec 2020, at 09:11, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > [...] >> >>> - generating (self contained) or using (handles) per URL access tokens >>> might be rather expensive. Can you sketch out how you wanna cope with that >>> challenge? >> >> A decent HMAC implementation takes about 1-2 microseconds for typical size >> of token we’re talking about. > > The generation of a self contained access token typically requires querying > claim values from at least a single data source. That might take more time. > For handle based tokens/token introspection, one needs to add the time it > takes to obtain the token data, which requires a HTTPS communication. That > could be even more time consuming.
This is typically true of identity-based tokens, where access to a resource is based on who is accessing it. But in a capability-based model this is not the case and the capability itself grants access and is not (usually) tied to an individual identity. Where you do want to include claims in a token, or tie capabilities to an identity, then there are more efficient strategies than looking up those claims every time you create a new capability token. For example, in my book I implement a variant in which simple capability URIs are used for access but these are bound to a traditional identity-based session cookie that can be used to look up identity attributes as required. This provides security benefits to both the cookie (CSRF protection) and the capability URIs (linked to a HttpOnly cookie makes them harder to steal). If you use macaroons then typically you’d mint a single token with the claims in it and then derive lots of individual tokens from it by appending caveats. For example, when generating a directory listing in a Dropbox-like app you’d mint a single token with details of the user etc and then derive individual tokens to access each file by appending a caveat like “file = /path/to/specific/file”. — Neil -- ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
