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

John Bradley <> Mon, 17 December 2018 21:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C7311129AB8 for <>; Mon, 17 Dec 2018 13:28:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 rgzjBF-GBeyT for <>; Mon, 17 Dec 2018 13:28:33 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 63A0F12958B for <>; Mon, 17 Dec 2018 13:28:33 -0800 (PST)
Received: by with SMTP id y20so15825138qtm.13 for <>; Mon, 17 Dec 2018 13:28:33 -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-language; bh=ZI/cccjbtYnH5bkeu/4jo9gJaLaB7sbEZcBP4GTwxTI=; b=Vs2HlXwJQBa3K8jv47wZ3M5/4O6RjZLVn4MOuRamMoHHQsxdbti4c6ObkuGa1EorwW xwnuRC7dde8UP2Tz4U5irELWeq6Qg8gQb3NV/OQXbMCa9ZgCtYx+1U17pOqc9HUlMZfq ikDtrY0zVpWPAg01nKYDIQrCtrZ0cqvRTL+hgjP8JzeLWACoxyqqocT/dJPBU3ZXuWeZ 44hTh7JR+GS/3/kgu0f0WF/h5uoog9fmarRie/FTr/5sDi/3FqaJ+u/ezymoGjiAdb4F nl35MOxVmXtcMVdVYdwgzbA9uhYbv8HdzS5vNi0RWTTK6hLM6S9wvtceEYltLQRT9epL iTRQ==
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-language; bh=ZI/cccjbtYnH5bkeu/4jo9gJaLaB7sbEZcBP4GTwxTI=; b=ZOeOlVt6sCKx4RvodPllkZkRR/3ZecJSBYKllO2EzEZNgb3DmJnaravbYcGyw6SJ9W 8INbjlTV0QpfRBe7VLpsLbqIpb15ztvH6VOg1sWQaCqUBB1Rs16H2XQX4T/BD2Hf9UBW vR3yDGY2ss/pHVHcsyjA/FjnK3AVF+zpRTn5P6dCsm03HAQUafjNCg2laWaTiCyuHVIp lIsiMhLG3g10urtYhwU+dZgwZV3gGc6EKuar7aJfmOFpXmJBHK4JLhHJnPIRYlcMBK3P OOOpnh/cPdSYrjHi6Y5q9SfCsbXHBOKa8dFpsgsGZZZ7W6AcuJ5MH0twtULlyiH6wqcF AWIg==
X-Gm-Message-State: AA+aEWZLGO1Qfkb9n2APxHWwCmRtHThVOBHnXVDHcxp7u29hiCMkLyuO 81p8XPjBkfMqS3NElNEyodPGbEs49kFw2g==
X-Google-Smtp-Source: AFSGD/VS01kPHU/MBol5Jhg5dh857WiqE3/6A2nY5p+0LbUvHkuReRGXim+bLWNRGtoUaDFZcO7WZg==
X-Received: by 2002:a0c:9659:: with SMTP id 25mr14365930qvy.3.1545082111356; Mon, 17 Dec 2018 13:28:31 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id t123sm6101919qkc.6.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Dec 2018 13:28:30 -0800 (PST)
From: John Bradley <>
X-Google-Original-From: John Bradley <>
References: <>
Message-ID: <>
Date: Mon, 17 Dec 2018 13:28:29 -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: multipart/alternative; boundary="------------5CABBC66F31D5DF2C0C0E2B5"
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 21:28:36 -0000

Yes that is a general problem with browsers and MTLS.

A separate token endpoint is probably useful.

I don't really see SPA doing mutual TLS as likely, however once MTLS is 
turned on on the token endpoint for some clients it can mess up other 
browser and non browser clients.

A separate endpoint in discovery is a good idea  they can always both 
point to the same place.

John B.

On 12/17/2018 12:26 PM, 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