Oops. Sorry, I believe I should have said, case 2. And why is case 2 impossible? The only time case 1 is valid in the redirect_uri is invalid.
Buhake Sindi On 21 February 2012 13:40, Buhake Sindi <buh...@googlemail.com> wrote: > Hi guys, > > OAuth 2, Draft 23, Paragraph 4.1.2.1 clearly states: > > If the request fails due to a missing, invalid, or mismatching redirection >> URI, or if the client >> identifier is missing or invalid, the authorization server SHOULD inform >> the resource owner of >> the error, and MUST NOT automatically redirect the user-agent to the >> invalid redirection URI. >> > > So, Case 1 is the only accepted case here. > > Buhake Sindi > > > On 21 February 2012 13:34, matake@gmail <mat...@gmail.com> wrote: > >> So the answer is "Show the error to the user without redirecting back to >> the client", right? >> I'm now developing OAuth2 and OpenID Connect ruby library, and both of >> them return errors >> >> case 1. redirect with error in query if response_type is "code" but it's >> not supported >> case 2. redirect with error in fragment if response_type is "token code", >> "token id_token", "token code id_token" or "code id_token" but it's not >> supported >> case 3. otherwise show error to the user without redirect since server >> cannot understand the response_type at all >> >> But other server might not understand some of response_types listed in >> case 2 at all and choose case 3 in such case. >> (ie. OAuth servers which don't understand OpenID Connect won't understand >> "id_token") >> >> So I'm afraid that it reduces interoperability, a bit. >> >> On 2012/02/21, at 13:22, William Mills wrote: >> >> I does allow some parts of your server config to be discovered. More of >> a problem in error responses is usually echoing back the user data, or >> allowing user enumeration for example. Care is required, but you don't >> have a ton of options here. >> >> ------------------------------ >> *From:* Igor Faynberg <igor.faynb...@alcatel-lucent.com> >> *To:* oauth@ietf.org >> *Sent:* Monday, February 20, 2012 9:37 AM >> *Subject:* Re: [OAUTH-WG] Quick question about error response for >> "response_type=unknown" >> >> Could there be a potential security hole in providing an error >> response? (Not that I see it, but many problems in the past had been >> caused by helpful responese.) >> >> Igor >> >> On 2/20/2012 11:57 AM, William Mills wrote: >> >> Respond with an error in protocol. Thta won't include a redirect, and >> the client has to know what to do. >> >> ------------------------------ >> *From:* nov matake <n...@matake.jp> <n...@matake.jp> >> *To:* oauth WG <oauth@ietf.org> <oauth@ietf.org> >> *Sent:* Monday, February 20, 2012 6:11 AM >> *Subject:* [OAUTH-WG] Quick question about error response for >> "response_type=unknown" >> >> Hi OAuthers, >> >> My apologies if you already discussed this. >> >> When OAuth server received unknown response_type, how should the server >> handle the error? >> >> 1. Show the error to the user without redirecting back to the client >> 2. Redirect back to the client including the error in query >> 3. Redirect back to the client including the error in fragment >> >> Since choosing 2 or 3 is impossible in this case, 1 seems reasonable for >> me. >> >> >> -- >> nov >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > > -- The Elite Gentleman
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
