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

[John Bradley <[e-mail]>]

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 <[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
>> 
>