Re: [OAUTH-WG] Suitable grant type for a Javascript use case

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-bounces@ietf.org] Im Auftrag von
> philip.kershaw@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.