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

John Bradley <> Fri, 22 January 2016 16:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 40A1F1B2A03 for <>; Fri, 22 Jan 2016 08:58:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ykH_XPkVHn5s for <>; Fri, 22 Jan 2016 08:58:11 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD2EA1B2A01 for <>; Fri, 22 Jan 2016 08:58:10 -0800 (PST)
Received: by with SMTP id o11so61752903qge.2 for <>; Fri, 22 Jan 2016 08:58:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=S/6gwuphmDjWMf8qjNFZquoZUqRQZjwi40HLqNwVA1M=; b=J2E4KTwBTSEqR/l4GB3J3/Y0oiuXatN3LjTuD3x/Apwf75djJZu/biFLpsyHsC/blM WKGegiij2kUlHd+Z1xwEt0dbRjcyJ03ZDGulZB+37i+v+7cc/UF51qFW9wF6N5qtJzSi 4UByuZAegHB5DSeuC/zw0J1xHKyiW0+U1W1wdim07Bm8f2D7lY40/K3WJkXCxV0FyMrd lXyNWQcjxw7m4g57LRUQYV1YvHz/1XhAfUMdoo0X4nzJEY9k6N1FOb4Fz0uxrdjtfYxA m6Zxf0GKUho26zXWLcSTc1rtx58eHN8vWoVu6bjntsrskzucouQF8JMc7VBMsGdQ2tPc lCtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=S/6gwuphmDjWMf8qjNFZquoZUqRQZjwi40HLqNwVA1M=; b=M0F5d9YdYx/Q/QfTR13M4FOVBAwV2h1gbw6gjlLSK6Nako/BGPHhlPDwq182yOhwY3 q37WkgonP9FDWbPuKtccIkEjhSYEFZPTUBu97AQ0JZR8Bv55Cuo2eSDb+flHhUH6xtZQ cI7XN3jbKiYu3Z84y8maNQOj4/uIRy1T1oSGJ8bbNUnw/oPgiW6mdrrLLBLqEKEHy61b NXg9jW3hpnvDoBJIZK2d7zoRajDR8l2xNcCp8VF/rpiCs6bpZAPB3/OSblekQ8PSuEN8 6TI+MorxlbU5Eqf3GQjt2neBu6WeAT0lfLhdeXHr3WnuVGFhSvukbZh1JZ69PTcgPooL +Ubg==
X-Gm-Message-State: AG10YOQyo8T0rygl/LoeyT9PuS9P+jSYAUMuGLLHofbjUbcbohix1NiW3HxsZs0ZHFHeaQ==
X-Received: by with SMTP id j85mr5227526qhc.88.1453481889733; Fri, 22 Jan 2016 08:58:09 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id m127sm3072587qhm.43.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Jan 2016 08:58:08 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_9C207140-6239-409A-BB0F-1F46597FD0A2"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley <>
In-Reply-To: <>
Date: Fri, 22 Jan 2016 13:58:04 -0300
Message-Id: <>
References: <> <> <>
To: Thomas Broyer <>
X-Mailer: Apple Mail (2.3112)
Archived-At: <>
Cc: "" <>
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: Fri, 22 Jan 2016 16:58:14 -0000

I agree that using a JWT is not the only way to do it, however many clients were not sending state at all or doing something insecure.

Particularly some people were having trouble with AS like Google who do exact redirect_uri matching and not being able to see how to pass multiple parameters in state rather then tacking extra query parameters on to the redirect_uri.

Documenting how to do it with a JWT and some of the security considerations specific to crating a useful state value has been useful to some people.

RFC 6819 has only a short section on state.

3.6 <>.  "state" Parameter

   The "state" parameter is used to link requests and callbacks to
   prevent cross-site request forgery attacks (see Section <>)
   where an attacker authorizes access to his own resources and then
   tricks a user into following a redirect with the attacker's token.
   This parameter should bind to the authenticated state in a user agent
   and, as per the core OAuth spec, the user agent must be capable of
   keeping it in a location accessible only by the client and user
   agent, i.e., protected by same-origin policy.

That is a bit hand wavy for some developers who wanted examples.

In any event I think we agree that dragging the whole JWT signed state draft into the checking state mitigation.

The mitigation makes checking the integrity of state by the client signing less important, as tampering with the value would be detected by the server in the code flow.

Perhaps as we develop the mitigation spec we could move some of the more critical advice on how to bind the browser instance to the state over to the mitigation draft.

John B.

> On Jan 22, 2016, at 1:32 PM, Thomas Broyer <> wrote:
> Hi John,
> Le jeu. 21 janv. 2016 15:42, John Bradley < <>> a écrit :
> We merged the state verification in with this rather than forcing people to also look at the JWT encoded State draft. <>.  
> While JWT encoded state is how I would do state in a client and at-least one client I know of uses it, it is not the only way to manage state,
> And not how I'd do it (unless you convince me that jwt is really better and the advantages outweigh the network bloat)
> and I am hesitant that developers might be scared away by thinking they need to encode state as a JWT.
> I decided that cross referencing them is better.   This made sending much simpler to describe.   
> Wouldn't linking to RFC 6819 be enough?
> I also removed the hashing from state.   That cut the text by about 2/3 by not having to describe character set normalization so that both the client and the AS could calculate the same hash.
> That also achieved the goal of not requiring a simple OAuth client doing the code flow to add a crypto library to support SHA256.
> Once we make a algorithm mandatory, we need to defend why we don’t have crypto agility eg support for SHA3 etc.  We would be forced by the IESG to add another parameter to the request to specify the hash alg if we went that direction.
> Given that we assume state to be public info in the request that an attacker can see, hashing state provides not much value for a lot of complexity that people may get wrong or not implement.
> I appreciate why from a theory point of view hashing it would have been better.
> If people really want it I can add it back.
> John B.
>> On Jan 21, 2016, at 3: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
>> <>
>> <>
> _______________________________________________
> OAuth mailing list
> <>
> <>