It is an interesting discussion, indicating that perhaps a best practices document is in order.
I have had several people ask me about SPA using OAuth recently. Until we get the W3C to finish fetch and extend it for token binding, we are going to have ongoing issues with bearer tokens in the browser and where to store them. I don’t know that there is a perfect solution for bearer tokens, but documenting the tradeoffs may be useful. John B. > On Sep 8, 2016, at 6:07 PM, Jim Manico <j...@manicode.com> wrote: > > +1 I think that's a very fair perspective. > > Putting sensitive data in LocalStorage is still a very bad idea. :) One XSS > and gone. Maybe XSS is not a big deal in a native app, but it's death to Web > apps. > Aloha, Jim > > On 9/8/16 10:20 AM, Oleg Gryb wrote: >> In SPA/REST env session ID is not very useful, so it's *an* auth token or >> tokens (not necessary OAuth one) that are stored in a cookie. It's used to >> get REST calls authenticated and yes, it usually runs in a multi-domain envs >> (think about micro services architecture). It makes me think that the value >> of HTTPOnly will continue diminishing, while the value of good cross-domain >> policies will increase. Just my opinion coming from my experience. I don't >> have big (or small) data available to confirm that. >> >> >> From: Jim Manico <j...@manicode.com> <mailto:j...@manicode.com> >> To: Oleg Gryb <o...@gryb.info> <mailto:o...@gryb.info>; Adam Lewis >> <adam.le...@motorolasolutions.com> <mailto:adam.le...@motorolasolutions.com> >> Cc: OAuth WG <oauth@ietf.org> <mailto:oauth@ietf.org> >> Sent: Thursday, September 8, 2016 12:51 PM >> Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage >> >> > Since SPA is a new normal now, it becomes extremely difficult to enforce >> > HTTPOnly flag, because JS needs access to secrets including those stored >> > in cookies. >> In a browser environment, this is only true when you need to make cross >> domain requests or are using cookie data for something other than session >> state. >> If your current page origin and the page you are requesting are the same, >> then your cookies can be HTTPOnly without impacting functionality. If you >> need additional cookies for other things that need to be accessed via JS, >> use a separate cookie. >> So sure, there are a few workflows in OAuth where you need to access "cookie >> data" from JS and HTTPOnly is not viable. But there are a few where it is >> viable. I don't think it's as simple as "we need to talk to cookie data via >> JS all the time.". >> Aloha, Jim >> On 9/8/16 8:15 AM, Oleg Gryb wrote: >>> Jim, >>> >>> It's outdated a bit. Since SPA is a new normal now, it becomes extremely >>> difficult to enforce HTTPOnly flag, because JS needs access to secrets >>> including those stored in cookies. 5-10 years ago I would always enforce >>> HTTPOnly and now - I can't. >>> >>> Thanks, >>> Oleg. >>> From: Jim Manico <j...@manicode.com> <mailto:j...@manicode.com> >>> To: Adam Lewis <adam.le...@motorolasolutions.com> >>> <mailto:adam.le...@motorolasolutions.com> >>> Cc: OAuth WG <oauth@ietf.org> <mailto:oauth@ietf.org> >>> Sent: Thursday, September 8, 2016 10:45 AM >>> Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage >>> >>> In the web world, cookies for session identifiers are much safer - since we >>> can use HTTPOnly cookies to protect them from theft via XSS. The same >>> mechanism is not possible for localStorage. Overall, security folk say >>> •keep sensitive data out of localStorage• since one XSS and it's stolen. >>> There is also a huge body of >>> work underway to make secure cookies even more so. >>> >>> I'm not sure how this translates to native apps. >>> >>> -- >>> Jim Manico >>> @Manicode >>> >>> On Sep 8, 2016, at 3:02 AM, Adam Lewis <adam.le...@motorolasolutions.com >>> <mailto:adam.le...@motorolasolutions.com>> wrote: >>> >>>> Hi, >>>> >>>> The WG is currently putting together best practices for native apps. I >>>> would like to better understand the best practices around ua-based-apps, >>>> especially as it relates to token storage. I've read various blog posts >>>> about the preference between storing tokens in cookies vs. Web Storage >>>> (localStorage/sessionStorage). The current set of specs are rather silent >>>> on the matter, as it is more of an implementation issue (but that is where >>>> most mistakes are made). >>>> >>>> What is the WG's guidance on this? >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> >> >> -- >> Jim Manico >> Manicode Security >> https://www.manicode.com <https://www.manicode.com/> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> > > -- > Jim Manico > Manicode Security > https://www.manicode.com > <https://www.manicode.com/>_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
