Re: [OAUTH-WG] Suitable grant type for a Javascript use case

[John Bradley <[e-mail]>]

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.


On Feb 5, 2014, at 7:01 PM, <[e-mail]> <[e-mail]> wrote:

> 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
> On 5 Feb 2014, at 21:49, John Bradley wrote:
> 
>> 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.
>> 
>> 
>> On Feb 5, 2014, at 6:22 PM, <[e-mail]> <[e-mail]> wrote:
>> 
>>> 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
>>> 
>>> On 5 Feb 2014, at 20:33, John Bradley wrote:
>>> 
>>>> 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 <[e-mail]> 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
>>>>> 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
>>>>>> 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 <[e-mail]> 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
>>>>>>> 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
>>>>>>>> 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:[e-mail]] Im Auftrag von
>>>>>>>> [e-mail]
>>>>>>>> Gesendet: Mittwoch, 5. Februar 2014 10:12
>>>>>>>> An: [e-mail]
>>>>>>>> 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?
>>>>>>>> 
>>>>>>>> Any help much appreciated.
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> Phil--
>>>>>>>> Scanned by iCritical.
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> 
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> --
>>> Scanned by iCritical.
>> 
> 
> --
> Scanned by iCritical.