On Tue, May 31, 2011 at 11:41 PM, Chuck Mortimore <cmortim...@salesforce.com> wrote: > It’s not entirely necessary; I’m just having a tough time figuring out any > practical difference between the implicit grant flow, and the webserver flow > with no credentials. In general I agree with your points, but I think we > have a similar, perhaps worse, scenario with relaxing the need for > credentials on the web server flow.
No doubt. =) I think it's unfortunate that the spec was changed to make the client credentials optional for the web server flow. As you say, it's a security problem for web apps. We are treating the client secret as mandatory in our deployments, and basically everyone who deploys the web server flow should do the same. It's a shame the spec is so vague on this point. The root cause of the spec ambiguity was disagreement over how to handle secrets for installed applications. I can think of three paths forward. - split out "installed app flow" from "web server flow". Use a new grant type. (DON'T switch installed apps to use the "implicit" grant type. That doesn't work either, because it doesn't return a long-lived credential. DON'T have the implicit grant type return a refresh token directly, either, since that causes serious security problems for real web apps that can keep client secrets.) - make the client secret mandatory, but tell people who are offended by client secrets in installed apps to use the string "notasecret" for all installed apps. - ignore the problem and leave the spec vague and insecure. > In terms of your example, wouldn’t basic XSRF protection in the state param > protect? Nope. Assume the following scenario: - bad guy has stolen refresh token - client web server has detected attack and changed their client secret - bad guy wants to find a way to keep using the refresh token If refresh tokens are returned without client authentication, the bad guy can do it as follows: - visit client. log in as account badguy1234. - client redirects to authorization server, including state=1234 - bad guy ignores redirect to authorization server, visits client callback server with refresh_token=stolen&state=1234 - client picks up stolen refresh token and associates it with badguy1234. - whenever badguy1234 visits the client web site, he can see data from the stolen refresh token. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
