When server cannot understand the response_type, it can't know where the error response should be included.
ex.) A JS client used response_type=code%20id_token and expected all returned parameters would be included in fragment. However server couldn't understand the response_type and returned error messages in query. Then client won't be able to handle the error. Actually, clients expects returned parameters in query only when it uses response_type=code, at least in current proposed response_types. (I'm thinking "current proposed response_types" as "code", "token", "code token", "token id_token", "code id_token" and "code token id_token") On 2012/02/21, at 20:42, Buhake Sindi wrote: > 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> >>> 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 > > > > > > > > > -- > The Elite Gentleman
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
