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

Mike Jones <Michael.Jones@microsoft.com> Tue, 13 December 2011 00:51 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 96BD511E8073 for <oauth@ietfa.amsl.com>; Mon, 12 Dec 2011 16:51:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.973
X-Spam-Status: No, score=-3.973 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id o1AC9mul2AMM for <oauth@ietfa.amsl.com>; Mon, 12 Dec 2011 16:51:47 -0800 (PST)
Received: from AM1EHSOBE003.bigfish.com (am1ehsobe003.messaging.microsoft.com []) by ietfa.amsl.com (Postfix) with ESMTP id 628A021F851A for <oauth@ietf.org>; Mon, 12 Dec 2011 16:51:46 -0800 (PST)
Received: from mail30-am1-R.bigfish.com ( by AM1EHSOBE003.bigfish.com ( with Microsoft SMTP Server id; Tue, 13 Dec 2011 00:51:42 +0000
Received: from mail30-am1 (localhost []) by mail30-am1-R.bigfish.com (Postfix) with ESMTP id B2FE15803F1 for <oauth@ietf.org>; Tue, 13 Dec 2011 00:51:42 +0000 (UTC)
X-SpamScore: -4
X-BigFish: VS-4(zzc85fh4015Lzz1202hzz8275bh8275dhz2fh2a8h668h839h)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received-SPF: pass (mail30-am1: domain of microsoft.com designates as permitted sender) client-ip=; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail30-am1 (localhost.localdomain []) by mail30-am1 (MessageSwitch) id 1323737502511498_23351; Tue, 13 Dec 2011 00:51:42 +0000 (UTC)
Received: from AM1EHSMHS017.bigfish.com (unknown []) by mail30-am1.bigfish.com (Postfix) with ESMTP id 78717700047 for <oauth@ietf.org>; Tue, 13 Dec 2011 00:51:42 +0000 (UTC)
Received: from TK5EX14HUBC106.redmond.corp.microsoft.com ( by AM1EHSMHS017.bigfish.com ( with Microsoft SMTP Server (TLS) id; Tue, 13 Dec 2011 00:51:41 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([]) with mapi id 14.02.0247.005; Mon, 12 Dec 2011 16:51:42 -0800
From: Mike Jones <Michael.Jones@microsoft.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: Using OAuth error_code to glean information from the server
Thread-Index: Acy5GRQ8DCUDRcpaSEuLOrJymTfgmAAF5PRw
Date: Tue, 13 Dec 2011 00:51:41 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739435F75FBF7@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <8DA2949DB77C2547B14546D35E22A20002D328EC@CH1PRD0302MB127.namprd03.prod.outlook.com>
In-Reply-To: <8DA2949DB77C2547B14546D35E22A20002D328EC@CH1PRD0302MB127.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435F75FBF7TK5EX14MBXC283r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: [OAUTH-WG] Using OAuth error_code to glean information from the server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Dec 2011 00:51:47 -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:

               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