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. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
