"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 <j...@manicode.com>
To: John Bradley <ve7...@ve7jtb.com>
Cc: Oleg Gryb <o...@gryb.info>; Adam Lewis <adam.le...@motorolasolutions.com>;
OAuth WG <oauth@ietf.org>
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
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 <j...@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 <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>
To: Adam Lewis <adam.le...@motorolasolutions.com>
Cc: OAuth WG <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>
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 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?
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
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
--
Jim Manico
Manicode Security
https://www.manicode.com _______________________________________________
OAuth mailing list
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
