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

Reply via email to