3 ms·

It doesn’t cover configuring scopes, on-behalf-of flows, getting tokens for different resources, etc. That’s half the stuff I’ve been struggling with lately (th

by billti 5y ago

It doesn’t cover configuring scopes, on-behalf-of flows, getting tokens for different resources, etc. That’s half the stuff I’ve been struggling with lately (that and popup blockers when trying to avoid the redirect flow). It’s a nice in-depth article for what it does cover though. This topic is so vast and confusing it’s no wonder security is often done poorly.

anderspitman 5y ago
Aren't popups not supposed to be blocked if it's in direct response to a use action, ie clicking a button? Or has that changed? I feel like Firefox has blocked popups I expected to work.
- billti 5y ago
  Sounds about right. The “direct” part being key. I think the framework I was using (Vue 2) was adding some “async” intermediary stuff the way I was using it between the DOM click event and the msal.js window.open call. Once it’s in a callback, it’s not “direct”. I simplified some code, restarted everything (WebPack hot reloading has been quirky too) and it’s working now. Still took an hour or two of my evening in reading a debugging though, and not exactly sure WHY it went from broken to fixed <shrug>
- dwaite 5y ago
  Pop-up blocking is usually configurable now, with the option to allow or deny all pop-ups independent of whether it is a direct response to user action. Different browsers unfortunately have different definitions of "direct". Chrome, as you might expect, is most aggressive about carrying that user action forward. Others will discard that interaction in more cases, and may also simply lose that interaction on certain callbacks, such as in a fetch response or indexed db response.
beermonster 5y ago
Although not directly related I’d like to see a modern guide to tokens and cookies. There are lots of choices and then on top of that the choice of storage location. I think OWASP recommend cookies rather than localStorage but it would be good to see the different risks each protocol or storage location comes with in an authorative guide with the pros and cons of each and which shouldn’t be used and why. I.e. there seems to be lots of footguns on top of the complexity of having to choose the appropriate OAuth flow.
- dwaite 5y ago
  > I think OWASP recommend cookies rather than localStorage but it would be good to see the different risks each protocol or storage location comes with in an authorative guide with the pros and cons of each and which shouldn’t be used and why. I.e. there seems to be lots of footguns on top of the complexity of having to choose the appropriate OAuth flow. The mental model I have for web storage these days is of three buckets per site: 1. Server data like secure-http-only cookies and negotiated information like HSTS 2. Javascript-accessible persistent storage 3. Javascript-accessible session storage Databases, Javascript storage API and cookies get partitioned into these buckets per site (e.g. eTLD+1). Some browsers may also extend these to support unique state for embedded sites - an advertising script can set a tracking cookie, but it will have a different cookie for each domain that the script is placed on. Likewise to prevent tracking, they may put the actual page caching into per-site storage (possibly a 4th bucket) The browser may have its own expiration policies for these buckets in addition to any policy you set - Safari for instance will expire javascript-accessible persistent storage after a week of active use without interacting with a site, even if the cookies have an expires header farther in the future. The browser exposes this data set as cookies, caches, local/session storage api, IndexedDB, and negotiated behavior like HSTS. A guide to understanding all of these would be useful. But generally, the combined "most restrictive" browser behavior is that these are just different views on top of the same storage buckets. The significant odd-one-out is a HttpOnly and Secure cookie. This may have a different expiration policy, and may be strongly desirable for say authentication systems which are trying to remember a user or device for an extended period of time, possibly for a risk tracking basis. These cookies also tend to be the ones which are synchronized across browser instances - so they are valuable for single sign-on and behavioral synchronization with installed PWAs as well as for native app use cases using the browser for authentication. OWASP likely prefers cookies because they have policy options to be secure and http only - I as an attacker cannot downgrade to a fraudulent HTTP site to extract secure cookies, nor can I inject scripts that will exfiltrate HttpOnly session cookies.
- mooreds 5y ago
  Here's what FusionAuth recommends: https://fusionauth.io/learn/expert-advice/tokens/building-a-secure-jwt/#holding-tokens https://fusionauth.io/learn/expert-advice/tokens/building-a-... It's hard to give overall general advice because the level of care you should take with a token depends on what trouble occurs if it is stolen. Just as someone building a banking app needs to take more care than someone building a recipe sharing app, the proper token storage for each of these cases is different.
mooreds 5y ago
Thanks. I added a todo in our docs repo to improve the guide for this and some of the other suggestions: https://github.com/FusionAuth/fusionauth-site/issues/1155 https://github.com/FusionAuth/fusionauth-site/issues/1155

by billti 5y ago

anderspitman 5y ago

Aren't popups not supposed to be blocked if it's in direct response to a use action, ie clicking a button? Or has that changed? I feel like Firefox has blocked popups I expected to work.

billti 5y ago
Sounds about right. The “direct” part being key. I think the framework I was using (Vue 2) was adding some “async” intermediary stuff the way I was using it between the DOM click event and the msal.js window.open call. Once it’s in a callback, it’s not “direct”. I simplified some code, restarted everything (WebPack hot reloading has been quirky too) and it’s working now. Still took an hour or two of my evening in reading a debugging though, and not exactly sure WHY it went from broken to fixed <shrug>
dwaite 5y ago
Pop-up blocking is usually configurable now, with the option to allow or deny all pop-ups independent of whether it is a direct response to user action. Different browsers unfortunately have different definitions of "direct". Chrome, as you might expect, is most aggressive about carrying that user action forward. Others will discard that interaction in more cases, and may also simply lose that interaction on certain callbacks, such as in a fetch response or indexed db response.

beermonster 5y ago

Although not directly related I’d like to see a modern guide to tokens and cookies. There are lots of choices and then on top of that the choice of storage location. I think OWASP recommend cookies rather than localStorage but it would be good to see the different risks each protocol or storage location comes with in an authorative guide with the pros and cons of each and which shouldn’t be used and why. I.e. there seems to be lots of footguns on top of the complexity of having to choose the appropriate OAuth flow.

dwaite 5y ago
> I think OWASP recommend cookies rather than localStorage but it would be good to see the different risks each protocol or storage location comes with in an authorative guide with the pros and cons of each and which shouldn’t be used and why. I.e. there seems to be lots of footguns on top of the complexity of having to choose the appropriate OAuth flow. The mental model I have for web storage these days is of three buckets per site: 1. Server data like secure-http-only cookies and negotiated information like HSTS 2. Javascript-accessible persistent storage 3. Javascript-accessible session storage Databases, Javascript storage API and cookies get partitioned into these buckets per site (e.g. eTLD+1). Some browsers may also extend these to support unique state for embedded sites - an advertising script can set a tracking cookie, but it will have a different cookie for each domain that the script is placed on. Likewise to prevent tracking, they may put the actual page caching into per-site storage (possibly a 4th bucket) The browser may have its own expiration policies for these buckets in addition to any policy you set - Safari for instance will expire javascript-accessible persistent storage after a week of active use without interacting with a site, even if the cookies have an expires header farther in the future. The browser exposes this data set as cookies, caches, local/session storage api, IndexedDB, and negotiated behavior like HSTS. A guide to understanding all of these would be useful. But generally, the combined "most restrictive" browser behavior is that these are just different views on top of the same storage buckets. The significant odd-one-out is a HttpOnly and Secure cookie. This may have a different expiration policy, and may be strongly desirable for say authentication systems which are trying to remember a user or device for an extended period of time, possibly for a risk tracking basis. These cookies also tend to be the ones which are synchronized across browser instances - so they are valuable for single sign-on and behavioral synchronization with installed PWAs as well as for native app use cases using the browser for authentication. OWASP likely prefers cookies because they have policy options to be secure and http only - I as an attacker cannot downgrade to a fraudulent HTTP site to extract secure cookies, nor can I inject scripts that will exfiltrate HttpOnly session cookies.
mooreds 5y ago
Here's what FusionAuth recommends: https://fusionauth.io/learn/expert-advice/tokens/building-a-secure-jwt/#holding-tokens https://fusionauth.io/learn/expert-advice/tokens/building-a-... It's hard to give overall general advice because the level of care you should take with a token depends on what trouble occurs if it is stolen. Just as someone building a banking app needs to take more care than someone building a recipe sharing app, the proper token storage for each of these cases is different.

mooreds 5y ago

Thanks. I added a todo in our docs repo to improve the guide for this and some of the other suggestions: https://github.com/FusionAuth/fusionauth-site/issues/1155 https://github.com/FusionAuth/fusionauth-site/issues/1155