On 5/31/11 11:56 PM, "Brian Eaton" <[email protected]> wrote:
On Tue, May 31, 2011 at 11:41 PM, Chuck Mortimore <[email protected]> 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. This is one reason we've favored implicit for native apps. 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.) Our approach to this issue has been to avoid returning refresh tokens to web URLs when using the implicit grant. We only support returning to one controlled URL on our server, or to a custom scheme url. It's bit tough to explain doc for developers though. - 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. Toyed with this idea. -cmort - 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
