Hi James, You raise an interesting point. I hadn't thought about the threat of Login CSRF.
> Q. Should an OAuth client app list the authorization server > in the Origin header of requests to resource servers? > > In OAuth (delegation) flows a server dynamically issues > credentials (such as a bearer token) to a client app to use > in subsequent HTTP requests to other servers. To combat > login cross-site request forgery (CSRF) attacks [1] (where > an attacker’s server issues the attacker’s credentials to a > client app ... But how will the client app get the "credentials" (bearer token) from the wrong authorization server? Even though the particular attack you describe may not work, OAuth is wide open to Login CSRF in a different way. An attacker can legitimately obtain an authorization code, and then cause the victim's browser to submit it to the client application, thus logging the victim in to the client application as the attacker (in a social login scenario such as "log in with Facebook"). I bet all applications that use OAuth to delegate authentication (to Facebook, Twitter, Google, LinkedIn, Yahoo, etc.) are vulnerable to this now. One solution I would propose is to have the client set a pre-session cookie in the user's browser before the first redirection and include the value of the cookie in the local state parameter that it sends to the authorization server. The authorization server later returns the local state together with the authorization code, and the browser adds the cookie, so the client can prevent the attack by checking that the value of the cookie agrees with the value it included in the local state. Francisco
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
