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 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
