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, <philip.kers...@stfc.ac.uk> <philip.kers...@stfc.ac.uk> 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, <philip.kers...@stfc.ac.uk> >> <philip.kers...@stfc.ac.uk> 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 <prateek.mis...@oracle.com> >>>> 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 <prateek.mis...@oracle.com> >>>>>> 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:oauth-boun...@ietf.org] Im Auftrag von >>>>>>>> philip.kers...@stfc.ac.uk >>>>>>>> Gesendet: Mittwoch, 5. Februar 2014 10:12 >>>>>>>> An: oauth@ietf.org >>>>>>>> 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 >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> -- >>> Scanned by iCritical. >> > > -- > Scanned by iCritical.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
