Subject: [OAUTH-WG] [Technical Errata Reported] RFC6749 (3880)

From: RFC Errata System <[email-masked]>
Date: Tue, 4 Feb 2014 08:13:38 -0800 (PST)

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3880

--------------------------------------
Type: Technical
Reported by: Eriksen Costa <[email-masked]>

Section: 10.16

Original Text
-------------
For public clients using implicit flows, this specification does not
provide any method for the client to determine what client an access
token was issued to.

Corrected Text
--------------
For public clients using implicit flows, this specification does not
provide any method for the authorization server to determine what
client an access token was issued to.

Notes
-----
A client can only know about tokens issued to it and not for other clients.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6749 (draft-ietf-oauth-v2-31)
--------------------------------------
Title               : The OAuth 2.0 Authorization Framework
Publication Date    : October 2012
Author(s)           : D. Hardt, Ed.
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Dick Hardt <[email-masked]>
Date: Tue, 4 Feb 2014 08:16:37 -0800

This change is appropriate and reflects the intent of the statement.

On Tue, Feb 4, 2014 at 8:13 AM, RFC Errata System <[email-masked]
> wrote:

---

From: John Bradley <[email-masked]>
Date: Tue, 4 Feb 2014 13:33:26 -0300

The text in 10.16 is correct.

This is a security consideration that has caused serious problems for Facebook and other implementers.

In the Implicit flow there is no way for a client to know if a access token was issued to it or another client.

The UA presenting the access token in an implicit flow may be the resource owner but may also be any other client that has ever received an access token for the resource.

In the implicit flow the Authorization server knows what client it has issued a access token to via the registered redirect URI.

The change doesn't reflect the intent of the security consideration.

John B.

On Feb 4, 2014, at 1:13 PM, RFC Errata System <[email-masked]> wrote:

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

---

From: Phil Hunt <[email-masked]>
Date: Tue, 4 Feb 2014 08:58:29 -0800

+1

Phil

> On Feb 4, 2014, at 8:33, John Bradley <[email-masked]> wrote:
>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 4 Feb 2014 10:27:47 -0800

My bad, sorry.

On Tue, Feb 4, 2014 at 8:58 AM, Phil Hunt <[email-masked]> wrote:

> > In the Implicit flow there is no way for a client to know if a access
> token was issued to it or another client.
> >
> > The UA presenting the access token in an implicit flow may be the
> resource owner but may also be any other client that has ever received an
> access token for the resource.
> >
> > In the implicit flow the Authorization server knows what client it has
> issued a access token to via the registered redirect URI.
> >

---

From: Prateek Mishra <[email-masked]>
Date: Tue, 04 Feb 2014 10:50:53 -0800

Well, the proposed correction does point to a genuine security hazard

Specifically, when client instances share the same re-direct URI, 
typically mobile clients

this is independent of whether implicit or code flows are used

It is only injective clients - each of whose instances bind to unique 
redirect URLs - that can support discriminative Az servers

So I would re-phrase the proposed text as:

[quote]

For public, non-injective clients, this specification does not
provide any method for the authorization server to determine what
client an access token was issued to.

[\quote]

- prateek

---

From: Bill Mills <[email-masked]>
Date: Tue, 4 Feb 2014 10:56:10 -0800 (PST)

Agreed.

On Tuesday, February 4, 2014 8:17 AM, Dick Hardt <[email-masked]> wrote:

On Tue, Feb 4, 2014 at 8:13 AM, RFC Errata System <[email-masked]> wrote:

---

From: John Bradley <[email-masked]>
Date: Tue, 4 Feb 2014 17:22:48 -0300

It is true that a AS cannot tell what instance of a native client it is issuing a token to via the redirect URI.

10.16 is only talking about an attack on the client based on a lack of audience information. 

If there is a security consideration around AS differentiating between instances of public clients that should be documented separately.
It might be possible using dynamic registration to give each instance of a client a separate client_id but I don't think that is manageable if the AS needs to maintain state for each client_id.

Depending on the threat we are trying to mitigate using the forthcoming Proof of Possession spec to bind tokens to specific client instances may be a solution.

I think the issues need to be kept separate.

John B.

On Feb 4, 2014, at 3:50 PM, Prateek Mishra <[email-masked]> wrote:

> Specifically, when client instances share the same re-direct URI, typically mobile clients
> 
> It is only injective clients - each of whose instances bind to unique redirect URLs - that can support discriminative Az servers
>

---

From: <[email-masked]>
Date: Wed, 5 Feb 2014 09:12:24 +0000

Hi all,

I'm looking to apply OAuth for a particular use case with a Javascript client and would like to get some guidance with this.  Bear with me as I'm new to this list.

I have a Javascript client which needs to be deployed on a number of different sites for which we don't have control over the server-side code.  The client needs to obtain an access token to submit data to another 3rd party site on behalf of the user.  

We've looked at the Implicit Grant type (http://tools.ietf.org/html/rfc6749#section-4.2).  Our third party site hosts an Authorisation server and Resource Server.  The client provides a redirect URI to return the token to.  My understanding is that the redirect URI is a security measure to ensure the token is returned to an endpoint known to the Authorisation Server.  

However, in my case it is only the Javascript client that needs the token.  I can see how the token can be passed to the Javascript via step E in figure 4.  However, we have limited control over the site hosting the Javascript ('Web-hosted Client Resource' in Figure 4).  We can host Javascript but we can't easily alter any server-side code.  There's a danger that the server-side code will choke when it receives the redirect the URI containing the access token.  I'm wondering if there is a suitable workaround for this.  Can we dispense with the redirect URI or does this compromise security too far?  Perhaps we should be looking at an implementing an alternative grant type?

Any help much appreciated.

Cheers,
Phil-- 
Scanned by iCritical.

---

From: "Manfred Steyer" <[email-masked]>
Date: Wed, 5 Feb 2014 12:30:46 +0100

Hi Phil,

the server won't see the access-code, cause it is returned within the hash
that stays at the client-site: 
	http://.../returnUri#access_code=ABCDE. 

By definition, the returnURI has to be the URI that was registered for the
client. IMHO, you are only allowed to add additional URL-Parameters.

In my opinion, your use-case suits _very_ well to the implicit flow.

Wishes,
Manfred

-----Ursprüngliche Nachricht-----
Von: OAuth [mailto:[email-masked]] Im Auftrag von
[email-masked]
Gesendet: Mittwoch, 5. Februar 2014 10:12
An: [email-masked]
Betreff: [OAUTH-WG] Suitable grant type for a Javascript use case

Hi all,

I'm looking to apply OAuth for a particular use case with a Javascript
client and would like to get some guidance with this.  Bear with me as I'm
new to this list.

I have a Javascript client which needs to be deployed on a number of
different sites for which we don't have control over the server-side code.
The client needs to obtain an access token to submit data to another 3rd
party site on behalf of the user.  

We've looked at the Implicit Grant type
(http://tools.ietf.org/html/rfc6749#section-4.2).  Our third party site
hosts an Authorisation server and Resource Server.  The client provides a
redirect URI to return the token to.  My understanding is that the redirect
URI is a security measure to ensure the token is returned to an endpoint
known to the Authorisation Server.  

However, in my case it is only the Javascript client that needs the token.
I can see how the token can be passed to the Javascript via step E in figure
4.  However, we have limited control over the site hosting the Javascript
('Web-hosted Client Resource' in Figure 4).  We can host Javascript but we
can't easily alter any server-side code.  There's a danger that the
server-side code will choke when it receives the redirect the URI containing
the access token.  I'm wondering if there is a suitable workaround for this.
Can we dispense with the redirect URI or does this compromise security too
far?  Perhaps we should be looking at an implementing an alternative grant
type?

Cheers,
Phil-- 
Scanned by iCritical.

---

From: <[email-masked]>
Date: Wed, 5 Feb 2014 11:49:04 +0000

Hi Manfred,

> 	http://.../returnUri#access_code=ABCDE. 

That's excellent.  I hadn't picked that up in the text.  I think it would be really helpful to have an explicit note in 4.2.2 to highlight this point.

Thanks,
Phil

-- 
Scanned by iCritical.

---

From: Prateek Mishra <[email-masked]>
Date: Wed, 05 Feb 2014 10:33:08 -0800

Well, this means you are completely dependent on a security model that 
is based on a very specific property of HTTP
redirects. The User agent MUST NOT forward any component of a fragment 
URI in a redirect - you are depending on the user having
a conformant and uptodate user agent.

I would say that the authorization code grant has more robust security 
properties. From my perspective depending
on this type of subtle and complex requirement on other layers of the 
protocol stack is a considerable risk.

So you should factor that in your analysis of the security properties of 
your client.

- prateek

---

From: Justin Richer <[email-masked]>
Date: Wed, 5 Feb 2014 14:29:24 -0500

While you should always factor in an analysis of the security properties of your client, you should also realize that by hosting the client completely inside the browser, most of the benefits of the code flow go away. You're no longer able to separate the knowledge of different parts of the protocol, and so much of what you're protecting with the auth code doesn't actually apply anymore. 

Also, if the user is using a user agent that is not conformant or up to date, there's no need to sniff OAuth because it can just steal the primary credentials from the auth server connection directly -- so the counter argument is a bit of a red herring. Yes, it's a requirement for this to work properly, but it's a requirement for many other things to work properly also. 

 -- Justin

On Feb 5, 2014, at 1:33 PM, Prateek Mishra <[email-masked]> wrote:

> Well, this means you are completely dependent on a security model that is based on a very specific property of HTTP
> redirects. The User agent MUST NOT forward any component of a fragment URI in a redirect - you are depending on the user having
> I would say that the authorization code grant has more robust security properties. From my perspective depending
> on this type of subtle and complex requirement on other layers of the protocol stack is a considerable risk.
> 
> So you should factor that in your analysis of the security properties of your client.
> 
> - prateek
>> Hi Phil,
>>

---

From: Prateek Mishra <[email-masked]>
Date: Wed, 05 Feb 2014 11:40:31 -0800

Well, there is a fundamental difference between the security properties 
of implicit vs. code flow: in the former access tokens are passed via 
URLs (protected only by the fragment URI requirement), whereas in the
latter this is never the case. So I do see a foundational difference in 
security properties between the two. The core issue the type of artifact 
exposed in network flows in both the models.

Another way to put it would be: the authorization code flow is a 
re-purposing of the well known SAML SSO Web Artifact profile which has a 
long history of deployment and use. The implicit flow "simplifies" that 
but there
are definitely some consequences from a security point of view.

I can see that certain low-value clients (or even better, clients for 
whom the client issuing entity assumes no liability :-) can reasonably 
utilize the implicit flow. But it would be good if its weaknesses were 
kept in mind.

- prateek

---

From: John Bradley <[email-masked]>
Date: Wed, 5 Feb 2014 17:33:14 -0300

The implicit flow is intended to get a access code to JS clients in the browser.   It is true that you could use the code flow, but only if the AS token endpoint allowed CORES requests.

Given that the client is in the UA and has a direct TLS connection to the Authorization endpoint, from the clients point of view the call to the authorization endpoint and the call to the token endpoint are equally secure.   

Given that Java Script in the browser typically can't protect a client secret, the two flows are about equal in security for the AS.

It is true that people use implicit for things that they probably shouldn't, but to get a token to Java Script in the UA implicit is probably the best way to do it without jumping through extra hoops that don't add anything.

At some point we need to do a PostMessage binding for Implicit as an option passing the token in the fragment,  many implementations do that today for JS clients but it is not interoperable without a profile.

John B.

On Feb 5, 2014, at 4:40 PM, Prateek Mishra <[email-masked]> wrote:

> Well, there is a fundamental difference between the security properties of implicit vs. code flow: in the former access tokens are passed via URLs (protected only by the fragment URI requirement), whereas in the
> latter this is never the case. So I do see a foundational difference in security properties between the two. The core issue the type of artifact exposed in network flows in both the models.
> 
> Another way to put it would be: the authorization code flow is a re-purposing of the well known SAML SSO Web Artifact profile which has a long history of deployment and use. The implicit flow "simplifies" that but there
> I can see that certain low-value clients (or even better, clients for whom the client issuing entity assumes no liability :-) can reasonably utilize the implicit flow. But it would be good if its weaknesses were kept in mind.
> 
> - prateek

---

From: <[email-masked]>
Date: Wed, 5 Feb 2014 21:22:32 +0000

Thanks all - some interesting points raised.

I've used the Authorisation Code grant for a couple of other use cases on other projects.  The Implicit Grant is less desirable but it fits here for me because of the particular constraints of the client and its hosting environment.  The level of security required is low.

I'd be interested in finding out about the examples that use a PostMessage approach that you mention John.

Phil

-- 
Scanned by iCritical.

---

From: John Bradley <[email-masked]>
Date: Wed, 5 Feb 2014 18:49:09 -0300

You can use PostMessage if you control both the client and AS.

Google uses it in there identity toolkit if you use there g+ Java Script client. http://www.riskcompletefailure.com/2013/03/postmessage-oauth-20.html

There is some example code at https://code.google.com/p/oauth2-postmessage-profile

In OpenID Connect the same technique is used for session management. http://openid.net/specs/openid-connect-session-1_0-18.html

You can do it but it would be custom to your AS.

John B.

---

From: <[email-masked]>
Date: Wed, 5 Feb 2014 22:01:06 +0000

This looks along the same lines as the solution my colleague here has proposed but I was unsure of the security implications and unaware of any existing implementations.

I agree that a standardised profile for this would be helpful.

Thanks,
Phil

-- 
Scanned by iCritical.

---

From: John Bradley <[email-masked]>
Date: Wed, 5 Feb 2014 19:20:26 -0300

The security for PostMessage and fragment encoded is similar as long as you pre register the JS origin of the client and use TLS.  

Some have argued that PostMessage with a registered JS origin is a more secure way of doing CORES than using fragment encoding in a redirect.

With fragment encoding there is the possibility that if the AS allows wildcarding in redirect URI than an attacker may be able to find an open redirector and by inserting !# in the body of the redirect URI be able to turn off fragment processing in the browser.

Facebook has been attacked using this technique a number of times to extract access tokens for user accounts. 
http://isciurus.blogspot.com/2012/09/pwning-facebook-authorization-through.html

Prateek will likely point out that the code flow with a confidential client is more secure from open redirector attacks, making the code flow better for most cases.

However for public clients it is generally worse as any open redirect will receive the code without needing to trick the browser into turning off fragment processing.
The attacker can then exchange the code for an access token at the token endpoint and it is in.

Selecting the most secure option depends on a number of factors.

John B.

---

From: Eriksen Costa <[email-masked]>
Date: Tue, 4 Feb 2014 17:02:25 -0200

Could we make Mishra's suggestion simpler? Example:

For public clients using implicit flows, this specification does not
provide any method for the client to determine that an access token was
issued to its current instance.

I'm not sure if it is explicit enough, neither convinced about "instance"
(maybe "session"?) but it seems more in line with the rest of the
specification's wording.

Thank you for the clarification,
Eriksen

-- 
Blog: http://blog.eriksen.com.br
Twitter: @eriksencosta