Re: [OAUTH-WG] best practices for implicit grant / token storage

[Jim Manico <[e-mail]>]

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

-- 
Jim Manico
Manicode Security
https://www.manicode.com