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

Nat Sakimura <> Thu, 21 January 2016 08:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D75191A1A66 for <>; Thu, 21 Jan 2016 00:38:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YvlT9eIQ5lVT for <>; Thu, 21 Jan 2016 00:38:53 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AB9B61A1A62 for <>; Thu, 21 Jan 2016 00:38:53 -0800 (PST)
Received: by with SMTP id b35so26393687qge.0 for <>; Thu, 21 Jan 2016 00:38:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=WNf2GanSy6GKi8AoS9N2YPjOR3LRtxH1jTog/cD8pA4=; b=BXxNi06ZYgREXciDGwOaWppJ2/fT2BXkDrzUhkFsAR7cg8MfFzE896PLXdu7SVwNU5 Otuw/e/l+TGCGQ0APQX98hpQ4123/IJFxaPJHhrkGKkCBX70oaQYy4mCe5TWMOi9nrPe RLzZixvF3eiQLdpM50gu2TuCxdvEUn3M0OR1yZdRIVgwNGtTtxDt5d08Sf1MO6DAs25c 1MEZ70SdrMBe5U4NNO1LMQg6L4bPtGrElUDUSMth9CkWily/TpXrOH8UkUDMWbRD5dOF jUNqmCZOje2WzRtZF5N8rzLdVUZU03tPmHFbztioVX6kbMWJCJkFIO7iHOtdbH+Xv5+s 1T8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=WNf2GanSy6GKi8AoS9N2YPjOR3LRtxH1jTog/cD8pA4=; b=KCkfQsUyrgqSK4gyB/luJWmreWJVngMk4MwqgONvKszIZf4beZTv3kSTNDQCnrIGBq edNsf/JTMnKzm0r4l2TouBgKjh6h2hDzb2cRBGJYsrH7wj4GPSamUSsntpgF9sZTUdn0 E/Hvku7t0XikFBx/G4MqOQ4xJneveecScADruuvP1yqgE3Dm3nNjgAVy0tsBO+KZZXMP h4/pzwk2CGpc4/de46VgLTb4bQ6nOELMRZxUomaus2c0LaF3qSDSSm0TRMB3oTKPEkqb J+6YhtLTnNHXLh99FW+1HUNKoB+TUL7zDZfZ7wFrc21OJw4JOw0TaECk4zJUcmWntc8p h0FA==
X-Gm-Message-State: AG10YOSVgP1iXfS5n49WnmYzpS4H5WYUVEN++99sCDraoPzQkIdQx9QrnRTNNYvD5BVdsZJcjHCrHZyqpKMvPQ==
X-Received: by with SMTP id 11mr43309479qgn.34.1453365532647; Thu, 21 Jan 2016 00:38:52 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Nat Sakimura <>
Date: Thu, 21 Jan 2016 08:38:41 +0000
Message-ID: <>
To: Antonio Sanso <>, Hannes Tschofenig <>
Content-Type: multipart/alternative; boundary="001a11c151e24d6abb0529d40807"
Archived-At: <>
Cc: "" <>
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: Thu, 21 Jan 2016 08:38:57 -0000

Well, re-reading, I have a bit of problem with the draft.

It is defining a new concept 'issuer', which is not found in RFC6749, as
the authorization server's configuration information location. It is
returned in 'iss' authorization response parameter. On the other hand,
there is an existing concept of 'issuer' for identifying the authorization
server in OpenID Connect. e.g., Google's discovery document's URI is and issuer in
it is . This value MUST exactly match the "iss"
in ID Token.
Unfortunately, this does not match the value of OAuth issuer defined in
Section 2 of draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned
as specified in 3.1. As such, validation as specified in bullet 1 of
Section 4 fails in Google's case -- OR it means that the document is
internally inconsistent.

Also, I do not understand the value of OAuth issuer when there is no
configuration file but everything is determined in the developer
documentation. This is one of the assumption of RFC6749 and many OAuth
servers are operated like that. Technically, since the discovery document
does not exist, it is an empty string, which fails the validation rule set

As to section 5 is concerned, I could not read out what threat it is trying
to mitigate. Is it trying to address the case that the client is not doing
a proper state check? From section 6, it seems it is trying to do the
binding between the authorization request and the token request, but if
that is the case, is it not better to just use PKCE than introducing
something new?

The draft-sakimura-oauth-meta-05 approach is similar, but it avoids these
Instead of relying on 'issuer' concept, it uses token endpoint URI. Per
discussion in Yokohama, the identifier that distinguishes the authorization
server is the URI of the authorization endpoint uri. This is the trust
anchor of the entire flow, and it exists even if the client is not using
discovery of any kind. If you cannot trust this endpoint, everything
breaks. Oauth-meta chains the trust through metadata step by step.

In case of 'code' flow, the next step on the server side is the token
endpoint uri. This is returned in a parameter called 'turi', a shorthand
for token endpoint uri. The validation rule is that the client MUST check
that turi and the token endpoint uri that is previously known to the client
exactly matches. (Actually, a simpler way is just use the value returned in

Then, the client sends the token request to turi. If additional security
through authorization and token request binding, or making sure that the
client instance is really the intended audience, then use PKCE [RFC7636].
The client_id parameter in draft-jones-oauth-mix-up-mitigation-01 does not
help in the case of public client, but PKCE works.

In addition, draft-sakimura-oauth-meta-05
<> [1] provides
other goodies as well, such as HATEOAS. It achieves all these by the full
use of RFC5988 and introducing very little new things. It is only one page!

So, IMHO, the combination of draft-sakimura-oauth-meta-05 and RFC7636 seems
to be a better solution.

   - It does not break the existing implementations;
   - It does not confuse the reader by defining two concepts of issuer
   depending on the context;
   - It works in the case that the configuration is done through the
   developer documentation. i.e., it does not require yet to be defined
   discovery spec.
   - It works for public client as well;
   - It enables HATEOAS - Yes. It makes OAuth finally RESTful!;

There is one discussion point that I want to raise for oauth-meta.
Currently, the authorization response metadata such as turi are returned as
query parameters. This is to enable the dynamic reallocation of the
endpoints, and adhere to the HATEOS principle. If you do not need this
dynamism, then there is an alternative proposal that I have, that makes it
extremely simple to implement for the server. In this case, the client just
sends HEAD request to the authorization endpoint. Then the authorization
endpoint returns 200 OK with turi in the header. e.g.,

 HTTP/1.1 200 OK
   Link: <>; rel="turi",
   Content-Type: application/JSON; charset=utf-8

This can be achieved without touching the authorization endpoint code, but
just by configuration. In case of apache, use 'header append' in the apache
configuration. If we take this course, then there is another advantage to
be added:

   - You do not need to change the server code.

Is it not attractive?


Nat Sakimura


2016年1月21日(木) 15:14 Antonio Sanso <>:

> +1 for adoption
> On Jan 19, 2016, at 12:49 PM, Hannes Tschofenig <>
> wrote:
> > Hi all,
> >
> > this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
> >
> >
> > Please let us know by Feb 9th whether you accept / object to the
> > adoption of this document as a starting point for work in the OAuth
> > working group.
> >
> > Note: This call is related to the announcement made on the list earlier
> > this month, see
> > More
> > time for analysis is provided due to the complexity of the topic.
> >
> > Ciao
> > Hannes & Derek
> >
> > _______________________________________________
> > OAuth mailing list
> >
> >
> _______________________________________________
> OAuth mailing list