Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

John Bradley <> Mon, 25 January 2016 17:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 15E221B3780 for <>; Mon, 25 Jan 2016 09:32: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 P8paXVoGRWNa for <>; Mon, 25 Jan 2016 09:32:09 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 82D791B379A for <>; Mon, 25 Jan 2016 09:32:09 -0800 (PST)
Received: by with SMTP id e32so114749553qgf.3 for <>; Mon, 25 Jan 2016 09:32:09 -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=5q5ipLu18k4viw2v3cHjw0Aht3JXLGj1F35SZ/hHLxc=; b=uDV+sZq4nePqpZlj4vxAiGRnFKJsiGYBRt+HnUyssSmVCscglfBfbRpAA3mb48w3wb VCYz534Yx8YYszrg7AWkNAIxWx5uCBo9soDO20vkFftSwVs5e8InoQG4Mue7734bRnsH IWJrTErFpWj0RBK3xuNVfO2o8SAJBK9OrxLvYi/nUP034DSKc7uSNzD5XhS9QPOQic40 z23eezhTIXF0AYx8ZBzIcVnA5TwA0bPYYooPCneU7LBfcx0Oe0rM+Yz5s3uNX+LHsO3Z uaJezkpu92Tv15EsYbGpXAl2DpBSbEWHVAoYivty6UGYMBdConCXYdXorJxvwRA6BGfw Jjsw==
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=5q5ipLu18k4viw2v3cHjw0Aht3JXLGj1F35SZ/hHLxc=; b=LdJ44ajPjBNf9DxiX8DXiZ4qiQyK0GJxNVOyLtTUXQUFcTEc5QVt2x3tk0DuwvfhG/ t1S44WXSqho0SReulv4p4APjqoEUmi/ZggwCuJeB91Wk+tB+Dsd9jZ+toPP5zZSpioon 49N7Ip0pmeCZdsIsPr0abOXpeZVwB2FLjUr60nbBEuphW52D2+4YKDZTC62xe83mhANs OId7g2odYirRgRsvHDHeTUPiuElX35yYlQvHby2FpzXBElkFZhEzTdMbc2XcyDzfKw+b 9tuRxGMdc2aIXoyCtusZjCqvbIEipQMfLL/gm9yo56GFPEnWdSzsDdP5k5UdK1kkVaMH 0Jzg==
X-Gm-Message-State: AG10YOTyAYd+HowQq+gZQ+ANlEeMzoYRhuRaWHDxiOa2/v8w5KerlKPv7RVcDAzyVyUMJw==
X-Received: by with SMTP id 139mr24408700qhk.18.1453743128485; Mon, 25 Jan 2016 09:32:08 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id s64sm9094104qgd.28.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 09:32:07 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_F9F1556D-1419-4E98-B454-DD6D826476B5"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley <>
In-Reply-To: <>
Date: Mon, 25 Jan 2016 14:32:01 -0300
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: George Fletcher <>
X-Mailer: Apple Mail (2.3112)
Archived-At: <>
Cc: " WG" <>
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
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 17:32:14 -0000

No, client id_are scoped by issuer.  

There is no need for AS to make the client_id globally unique.

 The client needs to not allow two AS to provide it with the same issuer client_id pair.

That would probably be imposable for many clients anyway. 

For Connect clients typically manage configurations using issuer as the primary key.  I doubt may would support even two client_id from the same issuer.

For OAuth what clients do is slightly less clear.  In general they don’t have more than one AS per API do might try and organize things by RS or AS.

In principal a OAuth client might have two different AS each with a different client ID and that will be OK as long as the client_id in the request is the same as the one in the response.

So going to a new AS and getting back the same iss and client_id that you registered someplace else would be an error for the client.

I don’t think that is unreasonable.

John B.

> On Jan 25, 2016, at 12:30 PM, George Fletcher <> wrote:
> I'm still catching up... but to this point specifically...
> Doesn't this require that the same client_id NOT be used simultaneously at two (or more) Authorization Servers? If so, I don't believe that is a viable option. It's a little late in the game to be putting requirements on the AS as to how it generates it's client_id.
> Thanks,
> George
> On 1/25/16 9:11 AM, John Bradley wrote:
>> Returning the iss and client_id from the authorization endpoint per Mike’s draft allows the client to reject the authorization response and not leak the code.