Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

John Bradley <> Mon, 17 December 2018 22:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A8ACB129AB8 for <>; Mon, 17 Dec 2018 14:10:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.36
X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lfEP4-dBvlSH for <>; Mon, 17 Dec 2018 14:10:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 25663126C01 for <>; Mon, 17 Dec 2018 14:10:47 -0800 (PST)
Received: by with SMTP id q1so8301776qkf.13 for <>; Mon, 17 Dec 2018 14:10:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=axg+i75JXtbN+w+V36MKV78RGQNUOIXs/De/TQG7N7o=; b=VrkinFo+pL9ot26YpFrvByN6MqqhZrwCyws4GxTj2YDrhl5xlI/HZqS96uYpEJLvQ/ 7qJaIF5jWoZqWgyomMCqMnn8HWPwjhHsuy8gb/BtT1a2K/beY0yN8ElrXEnZrvN37gda zcF8DR0sum7KWi187qiM9v3qp8dztLDvt3bYVUHI3OYkHybNEK5w9SgRef2tnuQalsaT w3exR3Zny04rPS26plqLrd0Li5ai11t5tVNGzf+zoZEKSlPrktRa9EYTjmc/ZoVGbb1D OjhitkfDMNWAtFod8bZ8AStafoouzvFAmjSb44bRuW8K2l7o/qd7KpnaIX3av4O7VEHd rHsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=axg+i75JXtbN+w+V36MKV78RGQNUOIXs/De/TQG7N7o=; b=E/5h86MlXR0p1u/3bMrNBxHGMQW1OsBOdoQS34j2eNcCAwRvYvYe1Q0IGLZLxZKVOT LAKbxxklDwR+/EAqIbZTrtCtUcYBfO7a1+7Hxgx6UlmMgT5YjE2+GQhjHWavGUVt3GhC 6geLJbMC9kRUv1u9a3IGdQJOg06XMstb5TLtNb/VrZSeRw9VxCYEeAbcoS9syDlNOduK bSgLfkLXjDpuaruNDRPZS6tYQ3k6AB9hPQWoJYYUaA5WJy4G3L++idEUQDkIpFBIU4Iq Iot4GUsSIjKlZRkqk4eMZ9VOiOpg12iU70g+cnLH8PGuPP8LNP/Rrhsera3Zhh4bGazR +AMg==
X-Gm-Message-State: AA+aEWZ/OBWU/pBYBSF/Ap4vAEpZqbBEtzr75Zha2HjfkV825dUPKZqK FVuhcQ+q1WgNMY12W9UV/soVG9+YUJIBQA==
X-Google-Smtp-Source: AFSGD/W1mV8jwsP5ycFV3Fw1qZaBkJhdyB2Mcg0E8ChkigTamE/EhVIRgqOnr4oHs2+W+P9uhL+T9g==
X-Received: by 2002:a37:be02:: with SMTP id o2mr14065196qkf.133.1545084645347; Mon, 17 Dec 2018 14:10:45 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id q38sm8374164qtj.65.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Dec 2018 14:10:44 -0800 (PST)
From: John Bradley <>
X-Google-Original-From: John Bradley <>
References: <> <>
Message-ID: <>
Date: Mon, 17 Dec 2018 14:10:44 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Thunderbird/64.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Dec 2018 22:10:50 -0000

I think that works for those browsers if no certificates are installed 
for the browser.   We should test, but I think if any certificates are 
available to the browser then it will prompt.

John B.

On 12/17/2018 1:52 PM, Neil Madden wrote:
> I am currently running a Tomcat instance that I have configured to support, but not demand, client certificates using the certificateVerification=“optionalNoCA” setting. With this config I am able to authenticate a confidential client using mTLS, and yet connecting to the same server over HTTPS in either Safari or Chrome on Mac does not prompt me for any certificate. I don’t have any client certificates configured in my browser, so does this only happen if you do?
> Depending on the deployment scenario, it may also be possible to terminate TLS at a proxy and use a separate proxy for (intranet) mTLS clients vs public clients, but that may not suit every deployment.
> — Neil
>> On 17 Dec 2018, at 20:26, Brian Campbell <> wrote:
>> While there's been some disagreement about the specific wording etc., there does seem to be general consensus coming out of this WG to, in one form or another, recommend against the use of the implicit grant in favor of authorization code. In order to follow that recommendation, in-browser JavaScript clients will need to use XHR/fetch (and likely CORS) to make requests directly to the token endpoint.
>> Meanwhile there is the MTLS document utilizes TLS client certificates at the token endpoint for client authentication and/or certificate bound access tokens. The security BCP draft even recommends sender/key constrained access tokens and MTLS is close to the only viable way to do that at this time.
>> Unfortunately, however, these two things don't play very nice together. When a browser makes a TLS connection where a client cert is requested by the server in the handshake, even when client certificates are optional and even when it's fetch/XHR, most/many/all browsers will throw up some kind of certificate selection interface to the user.  Which is typically a very very bad user experience. From a practical standpoint, this means that a single deployment cannot really support the MTLS draft and have in-browser JavaScript clients using authorization code at the same time.
>> In order to address the conflict here, I'd propose that the MTLS draft introduce a new optional AS metadata parameter that is an MTLS enabled token endpoint alias. Clients that are doing MTLS client authentication and/or certificate bound access tokens would/should/must use the alternative token endpoint when present in the AS's metadata. While all other clients continue to use the standard token endpoint as they always have. This would allow for an AS to deploy an alternative token endpoint alias on a distinct host or port where it will request client certs in the TLS handshake for OAuth clients that use it while keeping the regular token endpoint as it normally is for other clients, especially in-browser JavaScript clients.
>> Thoughts, objections, agreements, etc., on this proposal?
>> PS Bikeshedding on a name for the metadata parameter is also welcome. Some ideas to start:
>> token_endpoint_mtls_alias
>> token_endpoint_mtls
>> mtls_token_endpoint_alias
>> mtls_token_endpoint
>> alt_token_endpoint_mtls
>> mtls_token_endpoint_alt
>> a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_should_use
>> equally_poor_idea_here
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
>> OAuth mailing list
> _______________________________________________
> OAuth mailing list