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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
