+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 <[email protected]> > *To:* Oleg Gryb <[email protected]>; Adam Lewis > <[email protected]> > *Cc:* OAuth WG <[email protected]> > *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 <[email protected]> <mailto:[email protected]> >> *To:* Adam Lewis <[email protected]> >> <mailto:[email protected]> >> *Cc:* OAuth WG <[email protected]> <mailto:[email protected]> >> *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 >> <[email protected] >> <mailto:[email protected]>> 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 >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > -- > Jim Manico > Manicode Security > https://www.manicode.com <https://www.manicode.com/> > > > _______________________________________________ > OAuth mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > > -- Jim Manico Manicode Security https://www.manicode.com
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
