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
