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