Subject: [OAUTH-WG] Using OAuth error_code to glean information from the server

From: Mike Jones <[email-masked]>
Date: Tue, 13 Dec 2011 00:51:41 +0000

I recently received an inquiry regarding invalid_client vs. invalid_grant.  It seems that there is a potential information disclosure in the specification with respect to how these error codes are used:

invalid_client
               Client authentication failed (e.g. unknown client, no
               client authentication included, or unsupported
               authentication method).  The authorization server MAY
               return an HTTP 401 (Unauthorized) status code to indicate
               which HTTP authentication schemes are supported.  If the
               client attempted to authenticate via the "Authorization"
               request header field, the authorization server MUST
               respond with an HTTP 401 (Unauthorized) status code, and
               include the "WWW-Authenticate" response header field
               matching the authentication scheme used by the client.

invalid_grant

               The provided authorization grant (e.g. authorization

               code, resource owner credentials, client credentials) is

               invalid, expired, revoked, does not match the redirection

               URI used in the authorization request, or was issued to

               another client.

If one uses invalid_client when the client is unknown and invalid_grant when the client credentials are invalid, then an attacker could deduce whether or not a particular client exists.

First, do people agree that this is a potential information leak and that the leak is meaningful?  If so, what mitigation might be suggested?  For instance, might a server choose to use a single error code for both (and potentially other) cases?

                                                            Thanks,
                                                            -- Mike

---

From: William Mills <[email-masked]>
Date: Mon, 12 Dec 2011 17:46:54 -0800 (PST)

I don't think the leak of client IDs is a big issue, in any cleartext protocol you can just sniff them.  We don't mandate SSL on the protected resources.

Anyone relying on ClientID for a stronger assurance will want to be using SSL and an unguessable ID anyway.

________________________________
 From: Mike Jones <[email-masked]>
To: "[email-masked]" <[email-masked]> 
Sent: Monday, December 12, 2011 4:51 PM
Subject: [OAUTH-WG] Using OAuth error_code to glean information from the server

 
invalid_client

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 12 Dec 2011 19:33:10 -0700

'Client credentials' needs to be removed from invalid_grant. It is not appropriate.

Use invalid_client all the way to a fully authenticate client. ANY failure to authenticate the client should result in invalid_client.

Use unauthorized_client for an authenticate client which is not permitted to use this grant type. There are no other issues with an invalid grant related to client credentials.

I'll drop it from the e.g. list.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Monday, December 12, 2011 4:52 PM
To: [email-masked]
Subject: [OAUTH-WG] Using OAuth error_code to glean information from the server

invalid_client

invalid_grant

               another client.

                                                            Thanks,
                                                            -- Mike

---

From: Shane B Weeden <[email-masked]>
Date: Tue, 13 Dec 2011 13:10:52 +1000

I don't think one can presume that client identifiers are any kind of
secret particularly given that for web-based flows they are transmitted in
browser redirects.

The "meaningful"-ness of the information is debatable as on the other hand
security best practices generally support the idea that the less an
attacker can ascertain from error messages the better.

From:	Mike Jones <[email-masked]>
To:	"[email-masked]" <[email-masked]>
Date:	13/12/2011 10:56 AM
Subject:	[OAUTH-WG] Using OAuth error_code to glean information from the
            server
Sent by:	[email-masked]

I recently received an inquiry regarding invalid_client vs. invalid_grant.
It seems that there is a potential information disclosure in the
specification with respect to how these error codes are used:

      invalid_client
                     Client authentication failed (e.g. unknown client, no
                     client authentication included, or unsupported
                     authentication method).  The authorization server MAY
                     return an HTTP 401 (Unauthorized) status code to
      indicate
                     which HTTP authentication schemes are supported.  If
      the
                     client attempted to authenticate via the
      "Authorization"
                     request header field, the authorization server MUST
                     respond with an HTTP 401 (Unauthorized) status code,
      and
                     include the "WWW-Authenticate" response header field
                     matching the authentication scheme used by the client.
      invalid_grant
                     The provided authorization grant (e.g. authorization
                     code, resource owner credentials, client credentials)
      is
                     invalid, expired, revoked, does not match the
      redirection
                     URI used in the authorization request, or was issued
      to
                     another client.

If one uses invalid_client when the client is unknown and invalid_grant
when the client credentials are invalid, then an attacker could deduce
whether or not a particular client exists.

First, do people agree that this is a potential information leak and that
the leak is meaningful?  If so, what mitigation might be suggested?  For
instance, might a server choose to use a single error code for both (and
potentially other) cases?

                                                            Thanks,
                                                            -- Mike