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> >> To: oauth WG <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 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
