Re: [OAUTH-WG] oauth-meta: turi allows user to mislead app

["Nat Sakimura" <[e-mail]>]

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:[e-mail]] On Behalf Of Manger, James
Sent: Thursday, January 28, 2016 11:38 AM
To: [e-mail]
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