+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 https://www.ietf.org/mailman/listinfo/oauth
