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

+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 <jim@manicode.com
>> <mailto:jim@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 <jim@manicode.com>
>>>     *To:* Oleg Gryb <oleg@gryb.info>; Adam Lewis
>>>     <adam.lewis@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 <jim@manicode.com> <mailto:jim@manicode.com>
>>>>         *To:* Adam Lewis <adam.lewis@motorolasolutions.com>
>>>>         <mailto:adam.lewis@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.lewis@motorolasolutions.com
>>>>         <mailto:adam.lewis@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