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

"Nat Sakimura" <> Mon, 25 January 2016 09:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0EC771B29EC for <>; Mon, 25 Jan 2016 01:52:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.609
X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EPbUoP970DuZ for <>; Mon, 25 Jan 2016 01:52:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 148571B2AEF for <>; Mon, 25 Jan 2016 01:52:23 -0800 (PST)
Received: from (unknown []) by (Postfix) with SMTP id 883A7472EE2; Mon, 25 Jan 2016 18:52:22 +0900 (JST)
Received: from ([]) by (unknown) with ESMTP id u0P9qMGn026353; Mon, 25 Jan 2016 18:52:22 +0900
Received: from (localhost.localdomain []) by (Switch-3.3.4/Switch-3.3.4) with ESMTP id u0P9qMkU058039; Mon, 25 Jan 2016 18:52:22 +0900
Received: (from mailnull@localhost) by (Switch-3.3.4/Switch-3.3.0/Submit) id u0P9qMIZ058038; Mon, 25 Jan 2016 18:52:22 +0900
X-Authentication-Warning: mailnull set sender to using -f
Received: from ([]) by (Switch-3.3.4/Switch-3.3.4) with ESMTP id u0P9qMtg058035; Mon, 25 Jan 2016 18:52:22 +0900
From: "Nat Sakimura" <>
To: "'Vladimir Dzhuvinov'" <>, <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Date: Mon, 25 Jan 2016 18:52:21 +0900
Message-ID: <021601d15756$15d13090$417391b0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0217_01D157A1.85BFDD70"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQLKG9YKnAuG9iZkuteuVWaKAtPS6AHNDI0sAn71RDUB5QC36QMiMoQvAjAOt08BdybVJAJGd++6ARhElgYCv4d0zQI3XCPOnG/xNlA=
Content-Language: ja
X-MailAdviser: 20141126
Archived-At: <>
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 09:52:31 -0000

Right, JWT client authentication prevents the “code phishing”. However, when you generalize it, it amounts to the phishing of any “bearer tokens”, including not only code+client_secret pair but also access token against resources. 


So, the general solution would either be: 


1)     Let the client know which endpoint is the legitimate endpoint to receive the token authoritatively; OR

2)     Stop using bearer tokens and move to PoP tokens. 


So, I did not deal with the JWT client authentication option in my blog post. 









PLEASE READ :This e-mail is confidential and intended for the

named recipient only. If you are not an intended recipient,

please notify the sender  and delete this e-mail.


From: OAuth [] On Behalf Of Vladimir Dzhuvinov
Sent: Monday, January 25, 2016 5:42 PM
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation


The token endpoint mix-up attack was originally discussed in the context of OIDC, in August 2015. Back then John Bradley noted that by simply replacing Basic client authentication with JWT (client_secret_jwt or private_key_jwt) the attack is successfully prevented. Yes, the authz code will be captured, but the bogus AS will not be able to replay it with the legitimate AS because the JWT used for client authentication is bound (via the "aud" claim) to the original token endpoint.

Is this going to be added to the list of solutions? Its usefulness is limited to confidential clients, but it's a good solution nevertheless.

JWT authentication helps in another case also - when the client by mistake sends out the token request over plain HTTP.



On 23/01/16 22:52, Nat Sakimura wrote:

Since we have been discussing in another thread and you guys may be a aware
of it in this thread, here is one of the problem statement for the mix-up
draft explaining why it does not solve the problem as it is written now.
It can be fixed to solve the problem, but then the overhead size will be
much larger and involves an extra round trip compared to oauth-meta draft.
for the details.
2016年1月22日(金) 18:11 Hans Zandbelt  <> <>om>:

+1 to everything Mike stated
On 1/22/16 2:04 AM, Mike Jones wrote:

I believe that it’s simpler and more elegant to return an issuer, from
which the discovery metadata document can be retrieved, which contains
**all** the configuration information about the authorization server,
than to return some of the configuration parameters but not most of them
(which is what the oauth-meta proposal does).  There’s lots more in a
typical discovery document than just a few endpoint addresses. For
instance, there are statements about what response types are supported,
other configuration choices, keys, etc.
I also think that returning the issuer is more future-proof than trying
to decide now what all the configuration information is that might want
to be verified by the client and hoping we get it right.  With the
issuer, assuming that discovery is supported, it can retrieve and check
all of it, should the client want/need to do so.  Even when discovery
isn’t supported, the issuer still provides a concrete identifier for the
authorization server that can be checked for equality.
We talked about the value of that approach in the side meetings in
Yokohama and people were supportive then.
                                                                 -- Mike
*From:*OAuth [] *On Behalf Of *John Bradley
*Sent:* Thursday, January 21, 2016 4:48 PM
*To:* Nat Sakimura  <> <>
*Cc:* <>  WG  <> <>
*Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
I will point out for clarification that this would be like IdP discovery
in openID 2 that everyone did.  I think IdP not doing RP discovery in
openID 2 is a weak argument.
There may be other evidence that RP will not do discovery, but if that
is the case why are we doing a OAuth discovery spec?
Many people see your spec as discovery as well just in a different way.
I think both ways can work, but doing both leaves too many options.
John B.
    On Jan 21, 2016, at 9:38 PM, Nat Sakimura < <> 
     <> <>> wrote:
    Still doing the analysis. We spent 1.5 hours today with John,
    George, nov and me on the OpenID Connect WG call on this issue. John
    explained the mitigation, but none of us was convinced that it works.
    Then, after the call, I and nov went on with various scenarios. The
    interim conclusion is that:
      * client_id response parameter does not help. There are legitimate
        cases that client_id duplicates out there and we cannot ban that.
      * iss response parameter does not help unless the discovery is
        performed and the value of iss is checked against the value of
        OAuth issuer inside the document. (<- Discovery becomes
        mandatory. From our experience on RP discovery step in OpenID
        2.0, chance of this being done properly seems to be rather slim.)
      * sending the state to the token endpoint helps in the case code
        was stollen, but code should not be stolen to start with.
    2016年1月22日(金) 7:59 John Bradley < <> 
     <> <>>:
        There have been a lot of discussions. I think Hannes posted some
        minutes of the F2F meeting we had with the security researchers.
        The problem can’t be mitigated without some action on the client
        side.  It boils down to the client making a request to AS1 (From
        it’s perspective) and getting back a response from AS 2 (that it
        thinks is AS1)
        This can be done if AS1 is a good AS but has it’s logs
        compromised so that an attacker can read them. Hans Zandbelt
        built a proof of concept for the attack.
        In some cases the attacker gets the code and the credential to
        use it at the good AS token endpoint and in others it just gets
        the code and can replay that at the client to extract
        information from the API through the client by binding the api
        access to a new account.
        PKCE unfortunately mitigates a different attack, where the
        client is impersonated and trys to replay a intercepted code.
        It however assumes the token endpoint is good, and is no help in
        the case of a compromised token endpoint.
        The client in these attacks is vulnerable because it relies on
        some local state, or the value of the state parameter to know
        who the response is coming from.  This allows a authorization
        request that is intercepted to be used to create a new request
        in that browser to a different AS, or trick the client into
        using a Authorization endpoint for a different authorization


        One problem is that OAuth doesn’t really have a unified concept
        of what a AS is.  Traditionally it is a Authorization endpoint
        URI, token end point URI and resource server URI that some one
        gives the client in some documentation.
        As ling as a client only talks to one AS then there is no
        problem.   However once a client is configured to talk to more
        than one AS, we have problems if one of those AS lies about it’s
        endpoints, or is compromised and used to attack another AS.   As
        a design goal you don’t want the overall  security to be limited
        by the weakest system.
        One approach as Nat promotes is to have the authorization
        endpoint return the next hop, token endpoint for code or RS URI
        for token. The token endpoint must also return the RS URI or the
        client must push the RS URI to the token endpoint or the
        attacker just replaces the RS URI in the config and captures the
        token that way.
        The other way is to provide a name for each AS as part of
        registration and the client not allow duplicate registrations
        with the same name.  When the response comes back the client
        checks the name against the one it made the request to. If the
        name dereferences to a discovery document then the client can
        check that name at registration or runtime to validate the net


        I think the two approaches mitigate the attack in similar ways.
        Nat’s is more REST friendly and returns the next hop as a
        parameter of header.
        The one Mike and I wrote up based on the meeting in Germany
        provides identifiers (iss and client_id) that can be checked for
        validity in the simple case and be dereferenced via .well-known
        to get the information Nat’s proposal is providing.
        Perhaps the main difference is Nat is using the token endpoint
        as the identifier for the AS and Mike’s is using location for a
        discovery document as the identifier.
        I don’t recall the reasons using the token endpoint as the
        identifier was rejected at the meeting.  Perhaps others can post
        the reasons.
        We need to close on this quickly, otherwise if we are indecisive
        fixes will not go into products for another year or so until
        this is a RFC.
        That is my main concern.
        John B.
            On Jan 21, 2016, at 11:50 AM, Josh Mandel < <> 
             <> <>> wrote:
            Thanks Nat - that's helpful. If both mitigations *can* work
            effectively, then I would like to see this group consider
            the decision between them carefully (if that hasn't happened
            yet). Again, don't hesitate to let me know if this is the
            wrong place/time for such discussion.
            At a high level, I would rather ask server developers to do
            some "coding", for two reasons:
            1. Most OAuth servers talk to many, many clients. So
            consolidating the security critical work in one place
            (server) is a net savings of work (rather than asking each
            client to implement these checks.
            2. OAuth server developers are typically more sophisticated
            than client developers, and therefore more likely to
            understand the implications and more likely to get these
            critical details correct. Asking each client developer to do
            something right is likely to result in heterogenius
            implementation and persistent security holes. But if the
            server does the heavy lifting, and clients just have to pass
            along an extra parameter, this is more likely to see
            consistent implementation (for example, clients will fail to
            work if misconfigured, which will prompt developers to fix
            On Jan 21, 2016 09:40, "Nat Sakimura" < <> 
             <> <>> wrote:
                Hi Josh,
                It is similar but slightly different IMHO.
                Section 4.6.4 of the RFC6819 is the access token
                phishing by a counterfeit resource server.
                The mix-up attack described here is the code phishing by
                a counterfeit token endpoint.
                In my view, both can be mitigated by the server
                returning the next step: i.e., authorization endpoint
                returning the legitimate token endpoint uri, and token
                endpoint returning legitimate resource endpoint uris.
                This involves no discovery endpoint, which is good.
                Your way also works. It is just the reverse of my
                proposal. The difference being that my proposal does not
                need any coding on the server but just configuration,
                and it can return more metadata if needed.
                2016年1月21日(木) 23:04 Josh Mandel < <> 
                 <> <>>:
                    Apologies if this is the wrong forum for my comment
                    (and please direct me to the appropriate place in
                    that case), but I have two questions about the
                    propose mitigation (and the thinking behind it) that
                    I think the write-up could address:
                    1. Could the writeup clarify whether/how the primary
                    "mixup" threat differs from what RFC6819 identifies
                    as in section 4.6.4?
                    2. Has the workgroup considered a mitigation that
                    puts more responsibility on the authorization
                    server, and less on the client? For example, if
                    would be helpful for the writeup to clarify why
                    having the client send an "audience field" (in the
                    terminology of RFC6819) to the authorization
                    endpoint would not mitigate the threat. (In that
                    scenario, the authorization server can recognize
                    that the audience does not correspond to a resource
                    server it knows, rather than asking clients to make
                    this check). I assume this approach has been
                    considered and rejected as an incomplete mitigation,
                    but I don't have visibility into where/how that
                    discussion went.
                    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

                    time for analysis is provided due to the complexity
                    of the topic.
                    Hannes & Derek
                    OAuth mailing list
           <>   <> <>
                    OAuth mailing list
           <>   <> <>
            OAuth mailing list
   <>   <> <>
OAuth mailing list <>

Hans Zandbelt              | Sr. Technical Architect <>  | Ping Identity


OAuth mailing list <>

Vladimir Dzhuvinov :: <>