Well, there is a fundamental difference between the security properties
of implicit vs. code flow: in the former access tokens are passed via
URLs (protected only by the fragment URI requirement), whereas in the
latter this is never the case. So I do see a foundational difference in
security properties between the two. The core issue the type of artifact
exposed in network flows in both the models.
Another way to put it would be: the authorization code flow is a
re-purposing of the well known SAML SSO Web Artifact profile which has a
long history of deployment and use. The implicit flow "simplifies" that
but there
are definitely some consequences from a security point of view.
I can see that certain low-value clients (or even better, clients for
whom the client issuing entity assumes no liability :-) can reasonably
utilize the implicit flow. But it would be good if its weaknesses were
kept in mind.
- prateek
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
