Phil, > What if strong authentication of client (between client and > AM) happened OOB? Instead of passing a client_assertion, why > not pass a client_token? In a sense we would be repeating > the pattern for users and applying it to clients. A client > use its own client_token to obtain access tokens.
Interesting question. Two answers: 1. That works, but the client_token is then a shared secret between client and server, and there is no difference with a client password established by registration of the client with the server. Registration is an out-of-bound process that establishes a shared secret. The registration process can use a SAML assertion. 2. The best answer, though, is that client authentication after the double redirection (after the client redirects the user to the server for user authentication, and the server redirects the user back to the client with the authorization code) only provides an illusion of security. Security hinges on the fact that the authorization code goes to the legitimate client. If it goes to an attacker, the attacker can send the authorization code to the client from its own browser, thus impersonating the legitimate user. The client will send the authorization code to the server to get an access token, and use the access token to access the legitimate user's resources for the benefit of the attacker. It does not matter how strongly the client authenticates itself to the server; the legitimate client is now working for the attacker! And if the authorization code is guaranteed to go to the legitimate client, there is no need for the client to authenticate itself to the server. Actually, client authentication after redirection is not completely useless. It can help limit the damage done by a successful attack. Here's how that goes. Without client authentication after the double redirection, if an attacker somehow gets the authorization code, he/she can do two kinds of damage: (i) he/she can use it to get an access token from the server (masquerading as a legitimate client vis-a-vis the server) and thus gain direct access to the legitimate user's resources, and (ii) he/she can use it to impersonate the legitimate user and log in to the client (in the common case where the client uses OAuth for "social login" a la Facebook Connect; the client will log the user in after successfully exchanging the authorization code for an access token). With client authentication after the double redirection, the attacker can do less damage after a successful attack. The attacker can try to get the authorization code in two different ways: (1) by setting up a bogus client that masquerades as the legitimate client vis-a-vis the user, and tricking the user into granting access to the bogus client; or (2) by somehow intercepting the authorization code as the server sends it to the legitimate client. If the attacker gets the authorization code by method (1), the attacker can do damage (i), but cannot do damage (ii) because, when the legitimate client tries to verify the authorization code by sending it to the server, the server will detect that the authorization code was not sent to the legitimate client (it was sent to the bogus client); the server will not send the access token, and the legitimate client will not log in the attacker. If the attacker obtained the authorization code by method (2), the attacker can do damage (ii), but cannot do damage (i) because the attacker will not be able to exchange the authorization code for an access token, given that the authorization code was sent to the legitimate client and the server wants the authorization code to be presented by whichever client it was sent to. Francisco
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
