Even if theoretically secure, I don't think it is a good idea to send turi and require the client app to confirm it matches (or send duri and match issuer+well-known...). It will be too tempting to client apps to just use the turi/duri value.
draft-jones-oauth-mix-up-mitigation-01 is slightly better in sending an "iss" id to match, instead of a web address to follow. However, "iss" is actually a URI and is defined as the basis for discovery. If an app did discovery based on "iss" from the redirect it would be insecure. So I think apps using different redirect URIs for different ASs is a better idea (which happens to be the fix suggested in the paper on the "IdP Mix-Up" attack). If we have to send something that another party should match, but not otherwise use, it might be better to send a hash instead of the actual value. That feel much harder for apps or servers to accidentally misuse insecurely. -- James Manger From: Nat Sakimura [mailto:n-sakim...@nri.co.jp] Sent: Thursday, 28 January 2016 3:02 PM To: Manger, James <james.h.man...@team.telstra.com>; oauth@ietf.org Subject: RE: [OAUTH-WG] oauth-meta: turi allows user to mislead app Hi James, Right. I thought of the man-in-the-browser case and was originally thinking of sending them in signed JWT(state,c_hash,a_hash,turi,ruri,duri,...) or sending HMAC(sha256, state+code+turi+ruri, client_secret) together but subsequently dropped the idea as anything is broken in the man-in-the-browser case. The bad user case did not occur to me then. I should not have dropped the idea. Incidentally, this probably fixes the cut-n-paste attack as well. For OpenID Connect, it amounts to returning these parameters in ID Token in the front channel. As you can expect, this is my preferred way. If we do not want any crypto, then there has to be additional checks. In case of duri, mandating the client to check that the duri = issuer + .well-known/openid-configuration. For turi, it has to match one of the entry listed in the discovery document or or pre-set configuration. The same applies for ruri. We probably want to have a cut-n-paste attack control in place as well. For the token endpoint response that does not go through user browser, it should be ok to accept it as true. -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James Sent: Thursday, January 28, 2016 11:38 AM To: oauth@ietf.org<mailto:oauth@ietf.org> Subject: [OAUTH-WG] oauth-meta: turi allows user to mislead app The OAuth-Meta draft <draft-sakimura-oauth-meta-05> returns the token endpoint (in a "turi" query parameter) when redirecting a user from the authorization endpoint back to an app. The app presumably then POSTs the "code" (also in the redirect) to "turi" to get an access token. However, apps typically send their client_secret to the token endpoint to authenticate. Sending a client_secret to a URI that came from a user is insecure. A RESTful OAuth would be a great improvement, but it doesn't look like providing the token endpoint (nor discovery endpoint) in a redirect is the right approach. -- James Manger
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
