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
