So only when sever understand the response_type but doesn't support it, it returns "unsupported_response_type" error. It sounds reasonable for me.
It will make some servers return "unsupported_response_type" with a redirect and some don't, though. Thanks. On 2012/02/21, at 23:07, John Bradley wrote: > If the Authorization server, doesn't understand the response_type and has no > other way to determine what sort of flow the client is expecting, I don't see > any choice other than returning a error to the user/browser. > > In the case of an unknown response_type the client could also be expecting > postMessage, or making a direct connection. You just don't know. > > There may be cases that the Authorization server could infer how to reply > based on the client_id, if the client perhaps doesn't have a client secret > issued to it, you could guess that it is using a fragment encoded flow. > > I however don't know that guessing is a good practice. Probably best to > always return an error response without a redirect. > > John B. > On 2012-02-21, at 8:34 AM, matake@gmail 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
