Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

George Fletcher <> Mon, 25 January 2016 20:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8AB331A00E6 for <>; Mon, 25 Jan 2016 12:12:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jQfr9KM49ndF for <>; Mon, 25 Jan 2016 12:12:00 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 329C41A00E4 for <>; Mon, 25 Jan 2016 12:11:58 -0800 (PST)
Received: from ( []) by (Outbound Mail Relay) with ESMTP id 3F7C03800072; Mon, 25 Jan 2016 15:11:57 -0500 (EST)
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (MUA/Third Party Client Interface) with ESMTPSA id 98D8B3800009C; Mon, 25 Jan 2016 15:11:56 -0500 (EST)
To: Mike Jones <>, "" <>
References: <>
From: George Fletcher <>
Organization: AOL LLC
Message-ID: <>
Date: Mon, 25 Jan 2016 15:11:56 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------020400080000070800030902"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; t=1453752717; bh=0IiBCrVhHeKWoelYfN4mIg6OAr2qu62MTzjsIVtgrwg=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=FutnaG5YK7zUYeyO5bQinwVZr+npkJGkKnpxPbbQkrUwYYL/e6SDVLgnbc/jOxy12 O7thYJOOT/voJQFgO5nXLSOAPLalOdsjB/WwAeQEwBnm/nu9p7loYkaJsPB/HS3nYx U51bMAqHkTM8YfGusqVHtpTiiQbEKo5k+MVaPvEM=
x-aol-sid: 3039ac1ade8d56a6818c3c92
Archived-At: <>
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Jan 2016 20:12:02 -0000

Thanks for the write up John and Mike!

1. Editorial: I'd add something like the following to the last paragraph 
in section 2. "However, if the authorization server does not support 
OAuth Discovery, then it MUST publicly define it's AS issuer URI." The 
point being that the client has to have a way to obtain this value so 
that it can compare it later on in the protocol.

2. Question: If OAuth2 discovery is not required, how does a simple 
issuer compare prevent the attack? It seems like the malicious AS could 
get the client to statically configure Good Issuer, Good AuthZ, Bad 
Token endpoint and assign the client a client_id that is valid at the 
Good AS. When the Good AS returns the response data it would include 
it's iss and the client_id which would match and the client would still 
send the code and client credentials to the Bad AS. I believe that 
supporting OAuth discovery is going to be required to fully mitigate 
this attack.

3. Question: In section 7.3 the phrase "unsigned cookie" is used but 
it's not clear exactly what that means. While the attacker can set 
cookies in the forged response, they shouldn't be able to set cookies on 
the specific domain of the AS. If the cookie identifying the AS session 
is HTTP Only and Secure, then the attacker should not be able to see or 
forge a value for this cookie. The attacker could bypass the browser 
completely and just forge a request to the client specifying whatever 
values they like. These could be taken from a valid session the attacker 
created and can see from their browser. It seems like the key protection 
in this case is binding the state value into the code so the code can't 
be substituted.


On 1/21/16 1:28 AM, Mike Jones wrote:
> John Bradley and I collaborated to create the second OAuth 2.0 Mix-Up 
> Mitigation draft.  Changes were:
> ·Simplified by no longer specifying the signed JWT method for 
> returning the mitigation information.
> ·Simplified by no longer depending upon publication of a discovery 
> metadata document.
> ·Added the “state” token request parameter.
> ·Added examples.
> ·Added John Bradley as an editor.
> The specification is available at:
> ·
> An HTML-formatted version is also available at:
> ·
> -- Mike
> P.S.  This note was also posted at and 
> as @selfissued <>.
> _______________________________________________
> OAuth mailing list

Chief Architect
Identity Services Engineering     Work:
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter:
Office: +1-703-265-2544           Photos: