Hacker News new | past | comments | ask | show | jobs | submit login

The offline attenuation concept is really cool. I wonder how many chained attenuations you could perform before you start to run into practical limitations with storing them attenuated token in cookies, etc.



It sounds neat - but in-practice it's something other schemes have had for yonks, albeit centralized instead of being entirely at the discretion of the subject (e.g. OAuth2's delegation grant), and there's the obvious risk of someone's token being used to counter-sign or delegate permission without their knowledge (this isn't unrealistic considering the sheer number of daily posters to StackOverflow who think browser's localStorage is an acceptable place to hold secrets and keys...).


What do you mean? How do you do an offline attenuation of an OAuth2 token?


You can’t do it offline; but in practice that isn’t a problem because IdPs generally are five-nines available.


No, it is a problem, because the motivating use case for offline attenuation is doing JIT minimization of tokens before sending them. IdP OAuth2 tokens tend to be all-powerful, a game-over break if stolen. That's why offline attenuation was invented.

You can say that offline attenuation and minimization doesn't matter; for a lot of applications, it probably doesn't. But you can't say OAuth2 has the same feature, and certainly not "had for yonks".


You can of course use Macaroons with OAuth, which was something that I tried to get the OAuth WG interested in, with little success. But I did get it added to my then employer’s AS product: https://neilmadden.blog/2020/07/29/least-privilege-with-less...

(Not sure why the images in that post are suddenly broken, will try to fix later).

This also reminds me that I need to finish off my own take on Biscuits/Macaroons that takes a completely different approach based on Diffie-Hellman. I call them Florentines.


It's a really good, clarifying post; I've had it in a tab for a week or so while I've been writing.


Where should web pages store secrets and keys?


You have a couple of options for storing tokens or other secrets like API keys that only need to be presented to a remote server.

* Secure, HTTPOnly cookies. This requires that your servers live on the same domain as the web page is being served from, but cookies will transparently be attached to any request and are unavailable to be exfiltrated.

* Some secrets can be stored outside of the browser javascript context so again can't be exfiltrated. This is pretty limited, but WebAuthn uses this for example.

* Keep the secrets server side in a session. You are still vulnerable to session riding, but not exfiltration of tokens.


Thesedays they typically use a (native) reverse-proxy as their gateway to the wider web, which manages their access-tokens/secrets for them.

c.f.: https://leastprivilege.com/2020/03/31/spas-are-dead/


I agree, the current OAuth2/OIDC path of having to inline a non-standard (at the moment) token exchange grant absolutely sucks.




Consider applying for YC's first-ever Fall batch! Applications are open till Aug 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: