Hi Manfred, On 5 Feb 2014, at 11:30, Manfred Steyer wrote:
> 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. > That's excellent. I hadn't picked that up in the text. I think it would be really helpful to have an explicit note in 4.2.2 to highlight this point. Thanks, Phil > 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 > -- Scanned by iCritical. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
