Re: [OAUTH-WG] Quick question about error response for "response_type=unknown"

["matake@gmail" <[e-mail]>]

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