+1000 on a OAuth Security Best Practices document. I'd be happy to review or help some.
I think right now the answer is: keep away from implicit grants and do not store bearer tokens in the browser. Instead, use the authorization code grant which only exposes bearer tokens intra-server. For /*web apps*/, I feel the only good place to store authentication, session or token information is in a HTTPOnly flagged cookie to keep JS away from sensitive information. Aloha, Jim On 9/8/16 12:38 PM, John Bradley wrote: > 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 >> <mailto: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> >>> *To:* Oleg Gryb <o...@gryb.info>; Adam Lewis >>> <adam.le...@motorolasolutions.com> >>> *Cc:* OAuth WG <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 >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> 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 >>> >>> >> >> -- >> Jim Manico >> Manicode Security >> https://www.manicode.com >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > -- Jim Manico Manicode Security https://www.manicode.com
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
