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

From: nov matake <[email-masked]>
Date: Mon, 20 Feb 2012 23:11:56 +0900

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

---

From: William Mills <[email-masked]>
Date: Mon, 20 Feb 2012 08:57:07 -0800 (PST)

Respond with an error in protocol.  Thta won't include a redirect, and the client has to know what to do.

________________________________
 From: nov matake <[email-masked]>
To: oauth WG <[email-masked]> 
Sent: Monday, February 20, 2012 6:11 AM
Subject: [OAUTH-WG] Quick question about error response for "response_type=unknown"
 
Hi OAuthers,

--
nov
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 20 Feb 2012 12:37:33 -0500

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:
> ------------------------------------------------------------------------
> *From:* nov matake <[email-masked]>
> *To:* oauth WG <[email-masked]>
> *Sent:* Monday, February 20, 2012 6:11 AM
> *Subject:* [OAUTH-WG] Quick question about error response for 
> "response_type=unknown"
>
> Hi OAuthers,
>
> [email-masked] <mailto:[email-masked]>

---

From: William Mills <[email-masked]>
Date: Mon, 20 Feb 2012 20:22:29 -0800 (PST)

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 <[email-masked]>
To: [email-masked] 
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

_______________________________________________
OAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/oauth 
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: "matake@gmail" <[email-masked]>
Date: Tue, 21 Feb 2012 20:34:29 +0900

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.

---

From: "matake@gmail" <[email-masked]>
Date: Tue, 21 Feb 2012 21:23:15 +0900

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 <[email-masked]> 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 <[email-masked]> wrote:
> The Elite Gentleman

---

From: John Bradley <[email-masked]>
Date: Tue, 21 Feb 2012 11:07:29 -0300

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.

---

From: "matake@gmail" <[email-masked]>
Date: Wed, 22 Feb 2012 00:11:31 +0900

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.

---

From: Buhake Sindi <[email-masked]>
Date: Tue, 21 Feb 2012 13:40:05 +0200

Hi guys,

If the request fails due to a missing, invalid, or mismatching redirection
> URI, or if the client

Buhake Sindi

On 21 February 2012 13:34, matake@gmail <[email-masked]> wrote:

> 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.
> 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 <[email-masked]>
> *To:* [email-masked]
> *Sent:* Monday, February 20, 2012 9:37 AM
> *Subject:* Re: [OAUTH-WG] Quick question about error response for
> "response_type=unknown"
>
>    ------------------------------
> *From:* nov matake <[email-masked]> <[email-masked]>
> *To:* oauth WG <[email-masked]> <[email-masked]>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Buhake Sindi <[email-masked]>
Date: Tue, 21 Feb 2012 13:42:53 +0200

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 <[email-masked]> 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

-- 
The Elite Gentleman

---

From: John Bradley <[email-masked]>
Date: Tue, 21 Feb 2012 12:45:28 -0300

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