Assuming that the preconditions of client_id and redirect_uri being correct are met, and only the response_type is unsupported but known, you would reply to the client in the appropriate way.
If the response_type is unknown then I think the only reasonable thing is to report the error to the resource owner without a redirect. This is only my interpretation of the spec. The OAuth spec is silent on this particular case. John On 2012-02-21, at 12:11 PM, matake@gmail wrote: > 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 >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
