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

Shane B Weeden <> Tue, 13 December 2011 03:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A589321F8532 for <>; Mon, 12 Dec 2011 19:11:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E5b8JRGIWbY1 for <>; Mon, 12 Dec 2011 19:11:15 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5162521F851F for <>; Mon, 12 Dec 2011 19:11:14 -0800 (PST)
Received: from /spool/local by with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <> from <>; Tue, 13 Dec 2011 03:06:36 +1000
Received: from ([]) by ([]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 13 Dec 2011 03:06:33 +1000
Received: from ( []) by (8.13.8/8.13.8/NCO v10.0) with ESMTP id pBD3B0Et4669620; Tue, 13 Dec 2011 14:11:03 +1100
Received: from (loopback []) by (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pBD3B04A001976; Tue, 13 Dec 2011 14:11:00 +1100
Received: from ( []) by (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pBD3B0ce001969; Tue, 13 Dec 2011 14:11:00 +1100
In-Reply-To: <>
References: <> <>
X-KeepSent: EDA06529:6C841E9C-4A257965:000A00B5; type=4; name=$KeepSent
To: Mike Jones <>
X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010
Message-ID: <>
From: Shane B Weeden <>
Date: Tue, 13 Dec 2011 13:10:52 +1000
X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.2FP1HF437 | June 7, 2011) at 13/12/2011 14:14:59
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
x-cbid: 11121217-1618-0000-0000-0000004F1F42
Cc: "" <>,
Subject: Re: [OAUTH-WG] Using OAuth error_code to glean information from the server
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Dec 2011 03:11:26 -0000

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 <>
To:	"" <>
Date:	13/12/2011 10:56 AM
Subject:	[OAUTH-WG] Using OAuth error_code to glean information from the
Sent by:

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:

                     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
                     which HTTP authentication schemes are supported.  If
                     client attempted to authenticate via the
                     request header field, the authorization server MUST
                     respond with an HTTP 401 (Unauthorized) status code,
                     include the "WWW-Authenticate" response header field
                     matching the authentication scheme used by the client.
                     The provided authorization grant (e.g. authorization
                     code, resource owner credentials, client credentials)
                     invalid, expired, revoked, does not match the
                     URI used in the authorization request, or was issued
                     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?

                                                            -- Mike
OAuth mailing list