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

William Mills <> Tue, 13 December 2011 01:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D73521F8880 for <>; Mon, 12 Dec 2011 17:47:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.426
X-Spam-Status: No, score=-17.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Q+ytUnqZSUy for <>; Mon, 12 Dec 2011 17:47:02 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 40FBB21F84FB for <>; Mon, 12 Dec 2011 17:47:02 -0800 (PST)
Received: from [] by with NNFMP; 13 Dec 2011 01:46:55 -0000
Received: from [] by with NNFMP; 13 Dec 2011 01:46:54 -0000
Received: from [] by with NNFMP; 13 Dec 2011 01:46:54 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 98999 invoked by uid 60001); 13 Dec 2011 01:46:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ginc1024; t=1323740814; bh=Tf3rA7FgZ6fzcWPKs0dUbbCYgobvA2QkgTcUHCIKKFQ=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=S+I/IeUxD0x8Tlu10CuXeegDAGcRsXV9zetTiSxHWWDw4nDpv+aNFUTzddLQ1zexPV11WqWO5eZxCro35RWJvGOqfSflkyy3lEbuLqgs4XsuIu8/Y5QmYw0B8u+NEItho18/TQsttUHYEeAYkvQ9nAXRmGzdfWnsnDh8Lwi0liE=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024;; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=V1Yi/mDtNJO5FrqR238mTWkj5Rx1itam4crh0JhtqCkSU+QrYwlcrPqQ6H+fM8aU0tbtPkLMqkDbxGuZoeouDgdoc1LFHFCSR30sZ3lPtXBzj2gB0YXnf95dZX3PmDlkstF+sBFb0B1+yXC0iQ4HMrcQSMg6pNBSKO9zb2jLH20=;
X-YMail-OSG: p96UtzsVM1kas6XakJnkIi2QmSTgrSfQ_KDpni87.eYROE5 EiyIrpOY58tB5ltG2_OoRtzkIst1jlZUBEvsFf7X8o5e0SB3e6V7XwBmnYEC gmCSDhXuikvz97Ca1BiyGF1YBANSqRlamSq8kxXYVY1ZaqJ24xZxxLYc0jd. ZRn494mS_e3uZ.d41NY.gijBn5GThpbW5npuIcPaixFACpcGg7E54UIE0A27 DA7dkpzBMHuOpT8Qs8qn4vLwEjcBX5VhoiHMxymsJK6a_0vT_NzdEsaQHRnf r0fy088aNJKGbadvXxxMGBe3drV4AT1FH3FWfsK9jNv67vE7E4VoFOns043F 7DiZTe5kySu123dPrbDMLELHlr33h2FjHiYfCzYrP4pigu5uuLQwMQSurwTn 1BgzyRmEVVRmKJ9x1ZsmPHTgj4iLUhtY8jNE-
Received: from [] by via HTTP; Mon, 12 Dec 2011 17:46:54 PST
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/
References: <> <>
Message-ID: <>
Date: Mon, 12 Dec 2011 17:46:54 -0800
From: William Mills <>
To: Mike Jones <>, "" <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1238014912-1519221104-1323740814=:90630"
Subject: Re: [OAUTH-WG] Using OAuth error_code to glean information from the server
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills <>
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Dec 2011 01:47:03 -0000

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 <>
To: "" <> 
Sent: Monday, December 12, 2011 4:51 PM
Subject: [OAUTH-WG] Using OAuth error_code to glean information from the server

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 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.
               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?
                                                            -- Mike
OAuth mailing list