It is nice to know that I may occasionally be correct:) For Server based confidential clients the risks are quite minimal as Justin points out. There are likely other more interesting things you could do if you already have the ability to run arbitrary code on the server.
No matter what flow or client you are using, passing the access token from that client to some other server as a method of authentication is not a good idea unless you have some way to guarantee that it is a legitimate client that hasn't been compromised. Creating a fake App with a stolen client ID is trivial. So passing access tokens as a proxy for authentication between unauthenticated apps is a recopy for disaster. It sort of falls under the category of bad things that can happen if you just make up new flows for tokens that are not in the spec. Where it gets a bit grey is public clients using the code flow. If you look at Sec 3.2.1 only confidential clients Must Authenticate to the token endpoint. A public client like a native app: A public client that was not issued a client password MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint (e.g. for the purpose of providing end-user context, client usage statistics). While you may assume that it is reasonable for a client with a code to make a request to the token endpoint including it's client_id and the server to only give out the access token if the client_id in the token request matches the one in the original authorization request. However the spec specifically doesn't require that. I think that it has to do with the precept of threat. If you are simply using OAuth strictly for Authorization then it would make mo sense for an attacker who gets a valid code to not use it directly to access the protected resource. However if you can escalate the codes privilege by impersonating the resource owner at a legitimate public client then an attacker might do it to get into another system. So if the public client is perhaps vulnerable. Now I can't imagine someone running a public client on a web server, but this would be a good reason not to. In general the public client would be a native app, and not easy to inject a stolen code into. I don't have a explanation as to why public clients using the code flow are not minimally identified via their client_id. I suspect most implementations are doing that if they have public clients using the code flow, but I have not tested that theory. So the code flow is safer but there are some things you need to be careful of with any public client. John B. On 2012-06-29, at 1:23 PM, Justin Richer wrote: > It's all about how you can swipe a token and inject it into another > application. It's easier to trap and inject a token in the implicit flow > because it's exposed to the user agent and there's no client secret tied to > the token's issuance. To get the same trick to work with the code flow on > server-based confidential clients, you'd need to inject your rogue token into > the client's configuration or state. With the implicit flow and on devices, > it's a bit easier just because the parts of the system that need access to > the token are more accessible. > > -- Justin > > On 06/29/2012 12:53 PM, Antonio Sanso wrote: >> Hi John >> >> On Jun 29, 2012, at 1:43 AM, John Bradley wrote: >> >>> Authenticating to the client is NOT safe with all of the flows >> you are perfectly right here. At the begin of this discussion and reading >> your blog post I was under the impression that this "attack" was tight to >> the use of the implicit grant flaw. >> But this is not actually the case as I could reproduce the same scenario >> against a client using the Authorization Code flaw. >> >> Regards >> >> Antonio >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
