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

From: Adam Lewis <[email-masked]>
Date: Thu, 8 Sep 2016 08:02:21 -0500

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?

---

From: Jim Manico <[email-masked]>
Date: Thu, 8 Sep 2016 07:45:54 -1000

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-masked]> 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).
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Oleg Gryb <[email-masked]>
Date: Thu, 8 Sep 2016 18:15:00 +0000 (UTC)

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-masked]>
 To: Adam Lewis <[email-masked]> 
Cc: OAuth WG <[email-masked]>
 Sent: Thursday, September 8, 2016 10:45 AM
 Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage

--Jim Manico@Manicode

Hi,

---

From: Jim Manico <[email-masked]>
Date: Thu, 8 Sep 2016 09:51:48 -1000

> 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-masked]>
>     *To:* Adam Lewis <[email-masked]>
>     *Cc:* OAuth WG <[email-masked]>
>     *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.
>
>     On Sep 8, 2016, at 3:02 AM, Adam Lewis
>     <[email-masked]
>     <mailto:[email-masked]>> 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).
>>
>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

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

---

From: Oleg Gryb <[email-masked]>
Date: Thu, 8 Sep 2016 20:20:03 +0000 (UTC)

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-masked]>
 To: Oleg Gryb <[email-masked]>; Adam Lewis <[email-masked]> 
Cc: OAuth WG <[email-masked]>
 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
  
  Jim, 
 Thanks, Oleg.  

 -- Jim Manico @Manicode   

  Hi,

---

From: Jim Manico <[email-masked]>
Date: Thu, 8 Sep 2016 11:07:36 -1000

+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.  
>
>
>     *To:* Oleg Gryb <[email-masked]>; Adam Lewis
>     <[email-masked]>
>     *Sent:* Thursday, September 8, 2016 12:51 PM
>     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
>>     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-masked]> <mailto:[email-masked]>
>>         <mailto:[email-masked]>
>>         *Cc:* OAuth WG <[email-masked]> <mailto:[email-masked]>
>>         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.
>>
>>>         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).
>>>
>     https://www.manicode.com <https://www.manicode.com/>
>
>

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

---

From: John Bradley <[email-masked]>
Date: Thu, 8 Sep 2016 19:38:30 -0300

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 <[email-masked]> wrote:
> 
> 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
> 
>> From: Jim Manico <[email-masked]> <mailto:[email-masked]>
>> To: Oleg Gryb <[email-masked]> <mailto:[email-masked]>; Adam Lewis <[email-masked]> <mailto:[email-masked]> 
>> Cc: OAuth WG <[email-masked]> <mailto:[email-masked]>
>> > 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
>>> From: Jim Manico <[email-masked]> <mailto:[email-masked]>
>>> To: Adam Lewis <[email-masked]> <mailto:[email-masked]> 
>>> Cc: OAuth WG <[email-masked]> <mailto:[email-masked]>
>>> On Sep 8, 2016, at 3:02 AM, Adam Lewis <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>> 
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>> 
>>> 
>> 
>> -- 
>> Jim Manico
>> Manicode Security
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> 
> 
> -- 
> Jim Manico
> Manicode Security
> https://www.manicode.com <https://www.manicode.com/>_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Jim Manico <[email-masked]>
Date: Thu, 8 Sep 2016 12:51:41 -1000

+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:
> 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.
>
>> On Sep 8, 2016, at 6:07 PM, Jim Manico <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> 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
>>
>>
>>> 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.  
>>>
>>>
>>>     > Since SPA is a new normal now, it becomes extremely difficult
>>>     to enforce HTTPOnly flag, because JS needs access to secrets
>>>     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.
>>>     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
>>>>         *Subject:* Re: [OAUTH-WG] best practices for implicit grant
>>>>         / token storage
>>>>
>>>>         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.
>>>>
>>>>>         practices around ua-based-apps, especially as it relates
>>>>>         to token storage.  I've read various blog posts about the

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

---

From: Oleg Gryb <[email-masked]>
Date: Fri, 9 Sep 2016 00:54:08 +0000 (UTC)

"keep away from implicit grants and do not store bearer tokens in the browser" - that would be practically impossible for the envs that I was writing about and "best practices"  that could not be enforced aren't worth much. I can formulate it in stronger terms: if OAuth wouldn't allow a JS client running in a browser its usability will be very low.

What could and should be improved in implicit grants is removing secrets from URL (fragment). That could be done as I've shown in the previous discussions.

      From: Jim Manico <[email-masked]>
 To: John Bradley <[email-masked]> 
Cc: Oleg Gryb <[email-masked]>; Adam Lewis <[email-masked]>; OAuth WG <[email-masked]>
 Sent: Thursday, September 8, 2016 3:51 PM
 Subject: 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

  
  
 +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

   

  Jim, 

 -- Jim Manico @Manicode   

  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 totoken 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?   

    

    

 -- 
Jim Manico
Manicode Security
https://www.manicode.com  _______________________________________________
 OAuth mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/oauth

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

---

From: Jim Manico <[email-masked]>
Date: Thu, 8 Sep 2016 14:58:01 -1000

> "keep away from implicit grants and do not store bearer tokens in the
browser" - that would be practically impossible for the envs that I was
writing about and "best practices"  that could not be enforced aren't
worth much. I can formulate it in stronger terms: if OAuth wouldn't
allow a JS client running in a browser its usability will be very low.

Are you sure you're not talking about OIDC or JWT's? The piece of advice
above is regarding using OAuth for delegation per the core spec. Advice
for Federation (OIDC) and advice for session management (putting JTW's
in cookies) would be different that recommending how to use OAuth for
delegation securely.

Fair?

- Jim

On 9/8/16 2:54 PM, Oleg Gryb wrote:
> "keep away from implicit grants and do not store bearer tokens in the
> browser" - that would be practically impossible for the envs that I
> was writing about and "best practices"  that could not be enforced
> aren't worth much. I can formulate it in stronger terms: if OAuth
> wouldn't allow a JS client running in a browser its usability will be
> very low.
>
> What could and should be improved in implicit grants is removing
> secrets from URL (fragment). That could be done as I've shown in the
> previous discussions.
>
>
>     *To:* John Bradley <[email-masked]>
>     *Cc:* Oleg Gryb <[email-masked]>; Adam Lewis
>     <[email-masked]>; OAuth WG <[email-masked]>
>     *Sent:* Thursday, September 8, 2016 3:51 PM
>     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
>
>
>     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.
>
>     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
>
>>     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.  
>>
>>
>>         *To:* Oleg Gryb <[email-masked]> <mailto:[email-masked]>;
>>         Adam Lewis <[email-masked]>
>>         > 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.
>>         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.
>>         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
>>>         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.
>>>
>>>             <mailto:[email-masked]>
>>>             *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
>>>>             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).
>>>>

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