Subject: [OAUTH-WG] Security concern for URI fragment as Implicit grant

From: Liyu Yi <[email-masked]>
Date: Mon, 27 Jun 2016 12:30:46 -0700

While we are working on a project with OAuth2 implementation, one question
arises from our engineers.

We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30,
it is specified that

(C)  Assuming the resource owner grants access, the authorization

        server redirects the user-agent back to the client using the

        redirection URI provided earlier.  The redirection URI includes

        the access token in the URI fragment.

For my understanding, the browser keeps the URI fragment in the history,
and this introduces unexpected exposure of the access token. A user without
authorization for the resource can get the access token as long as he has
the access to the browser. This can happen in a shared computer in library,
or for an IT staff who works on other employee’s computer.

Shouldn’t it be more secure if we change to use a post method for access
token, similar to the SAML does?

I feel there might be something I missed here. Any advices will be
appreciated.

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 29 Jun 2016 14:29:26 +0000

The client app could (and should) do a window.location.replace or
window.history.replaceState to remove the entry from the browser history.
AFAICT, this is out of scope of the OAuth specs because they're about the
protocol and interactions between the parties involved, not about securing
each one on its own.

That said, if the computer is shared between users, they should take care
of properly signing out, which should (in most cases) revoke tokens and, in
the case of client apps should also involve explicitly revoking the tokens
they've been handed out. So even if a token is present in the browser
history it shouldn't be usable. If the previous user hasn't signed out,
then he has bigger problems.

See also https://tools.ietf.org/html/rfc6819#section-4.4.2.2

As for the form post, see
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html

On Wed, Jun 29, 2016 at 4:08 PM Liyu Yi <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Jim Manico <[email-masked]>
Date: Wed, 29 Jun 2016 16:30:04 +0200

> Shouldn’t it be more secure if we change to use a post method for
access token, similar to the SAML does?

I say yes. But please note I'm very new at this and someone with more
experience will have more to say or correct my comments.

Here are a few more details to consider.

1) OAuth is a framework and not a standard, per se. Different
authorization servers will have different implementations that are not
necessarily compatible with other service providers. So there is no
standard to break, per se.

2) Sensitive data in a URI is a bad idea. They leak all over the place
even over HTTPS. Even in fragments.

3) Break the "rules" and find a way to submit sensitive data like access
tokens, session information or any other (even short term) sensitive
data in a secure fashion. This includes POST, JSON data payloads over
PUT/PATCH and other verbs - all over well configured HTTPS.

4) If you really must submit sensitive data over GET , consider
JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level
confidentiality and integrity.

Aloha,

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

On 6/27/16 9:30 PM, Liyu Yi wrote:
>
> While we are working on a project with OAuth2 implementation, one
> question arises from our engineers.
>
> We noticed at
> https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is
> specified that
>
>   
>
> For my understanding, the browser keeps the URI fragment in the
> history, and this introduces unexpected exposure of the access token.
> A user without authorization for the resource can get the access token
> as long as he has the access to the browser. This can happen in a
> shared computer in library, or for an IT staff who works on other
> employee’s computer.
>
>  
>
> Shouldn’t it be more secure if we change to use a post method for
> access token, similar to the SAML does?
>

--

---

From: Justin Richer <[email-masked]>
Date: Wed, 29 Jun 2016 10:30:38 -0400

The implicit flow was designed for in-browser clients that don’t have a server back-end. In these cases, keeping the data inside the browser entirely is exactly the goal: you don’t want to use query or form parameters because those get sent by the browser back to the server. That was the idea anyway, except that now new versions of Chrome also send the fragment back (as I understand things) so we’re in a bit of a lurch with our assumed security model. 

Even so, you’re absolutely right that the fragment can leak all over the browser. There are a few tricks you can do to mitigate this, like messing about with the history, but they’re patches at best. This is why the implicit flow is considered fairly insecure by most people in the community, and it really needs to be used only in the very limited context of an in-browser application, with limited lifetime access tokens (perhaps even tied to a live session at the AS). What you’re doing with the implicit flow, when used properly, is really more like a cross-domain session sharing.

 — Justin

> On Jun 27, 2016, at 3:30 PM, Liyu Yi <[email-masked]> wrote:
> 
> While we are working on a project with OAuth2 implementation, one question arises from our engineers.
> 
> We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30 <https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30>, it is specified that
> 
>   
> For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee’s computer.
> 
>  
> Shouldn’t it be more secure if we change to use a post method for access token, similar to the SAML does?
> 
> I feel there might be something I missed here. Any advices will be appreciated.
>

---

From: John Bradley <[email-masked]>
Date: Wed, 29 Jun 2016 11:10:33 -0400

I agree with Justin.

You should be using the code flow if it is a server based client.

The OAuth WG is considering better alternatives to using fragment encoding for in browser JS clients as well.  
For the moment the only standard for the in browser client is fragment encoding.  In the future we hope to have more modern methods based on post message.

For people using openID Connect who want a id_token in the front channel (Hybrid flow) they should use the form post response mode
 https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html <https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html>

Browsers now re-append  fragments across 302 redirects unless they are explicitly cleared this makes fragment encoding less safe than it was when originally specified.

John B.

> On Jun 29, 2016, at 10:30 AM, Justin Richer <[email-masked]> wrote:
> 
>> On Jun 27, 2016, at 3:30 PM, Liyu Yi <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: Oleg Gryb <[email-masked]>
Date: Thu, 30 Jun 2016 23:24:44 +0000 (UTC)

We've discussed access tokens in URI back in 2010 (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There were two major objectives when I was saying that it's not secure:
1. Fragment is not sent to a server by a browser. When I've asked if this is true for every browser in the world, nobody was able to answer.2. Replacing with POST would mean a significant performance impact in some high volume implementations (I think it was Goole folks who were saying this, but I don't remember now).
AFAIR, nobody was arguing about browsing history, so it's valid.
So, 6 years later we're at square one with this and I hope that this time the community will be more successful with getting rid of secrets in URL.
BTW, Jim, if you can come up with other scenarios when fragments can leak, please share. It'll probably help the community with solving this problem faster than in 6 years.
Thanks,Oleg.

      From: Jim Manico <[email-masked]>
 To: Liyu Yi <[email-masked]>; [email-masked] 
 Sent: Wednesday, June 29, 2016 7:30 AM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
   
 > Shouldn’t it be more secure if we change to use a post method for access token, similar to the SAML does? I say yes. But please note I'm very new at this and someone with more experience will have more to say or correct my comments. Here are a few more details to consider.
  1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
  2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
  3) Break the "rules" and find a way to submit sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
  4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
  Aloha,
 Jim Manico
Manicode Security
https://www.manicode.com 
 On 6/27/16 9:30 PM, Liyu Yi wrote:
  
  While we are working on a project with OAuth2 implementation, one question arises from our engineers. We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is specified that    (C)  Assuming the resource owner grants access, the authorization         server redirects the user-agent back to the client using the         redirection URI provided earlier.  The redirection URI includes         the access token in the URI fragment.   For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without  authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee’s computer.   Shouldn’t it be more secure if we change to use a post method for access token, similar to the SAML does? I feel there might be something I missed here. Any advices will be appreciated.  

 --

---

From: Jim Manico <[email-masked]>
Date: Fri, 1 Jul 2016 07:25:26 +0200

Oleg! Hello! Great to see you pop up here with a similar concern.

John Bradley just answered this thread with the details I was looking for (thanks John, hat tip your way).

He also mentioned details about fragment leakage:

"Browsers now re-append  fragments across 302 redirects unless they are explicitly cleared this makes fragment encoding less safe than it was when originally specified"

Again, I'm new here but I'm grateful for this conversation.

Aloha,
--
Jim Manico
@Manicode

> On Jul 1, 2016, at 1:24 AM, Oleg Gryb <[email-masked]> wrote:
> 
> 1. Fragment is not sent to a server by a browser. When I've asked if this is true for every browser in the world, nobody was able to answer.
> 2. Replacing with POST would mean a significant performance impact in some high volume implementations (I think it was Goole folks who were saying this, but I don't remember now).
> 
> Thanks,
> Oleg.
> I say yes. But please note I'm very new at this and someone with more experience will have more to say or correct my comments.
>> We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is specified that
>>