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

Neil Madden <> Fri, 28 December 2018 17:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6BF08131058 for <>; Fri, 28 Dec 2018 09:50:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hEJoQWH2xadB for <>; Fri, 28 Dec 2018 09:50:27 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B1DE131053 for <>; Fri, 28 Dec 2018 09:50:27 -0800 (PST)
Received: by with SMTP id r24so26308329wmh.0 for <>; Fri, 28 Dec 2018 09:50:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=69pfBM1/bc6pcIOFG/qlADF4dAPqCRvZIBvySGtA83k=; b=Oit9oLwPJWOgenXexs8jLRaBCV22/FWsWhX71lbU8l3S3r1YuDvrNzjpBCNCEIW3+P YzfYd2OQm/jP2xr0RAsxIfsbFZ2hgmQOsYBU1v8ib4NN+3VxOyrr12CSks+x7qPPo7Iz j+onvLSUAHscyx8i6zZFRVh3l0t1XZK2wkLfE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=69pfBM1/bc6pcIOFG/qlADF4dAPqCRvZIBvySGtA83k=; b=Y6jvDk6PrdwtTPOYj9d3ijp8nKLRtVhR6TMDoSn9th6D19C6E1VOKJBX167e4cKSb3 E06dbygjJM5n/12G1nUEvMCpdQCravJqGLCS/1UBPw/qTAjDOlHQnV2L8ukuAifQYrSK mre5+z/XDKGRo6nLxtmfH9XT8sF0U7ekFEMKDgHuMcOz89uWlCsLNlpwSW12yShK5qbw 1SyH5WV96NTJ1xxI8NAwahDvedShaJ2GAsK0vLmM8IGE7YH+VG1bBRV+5Ru5IDyu5Iyc XamdHD9+dBn8FLdh3kNMFOUhNCZO1xIECtFcuWvlAIkGxIJgkftusYxqZaRUOF1nHJ5W ytrA==
X-Gm-Message-State: AA+aEWYJbkV8mATwR4XX2rTh+2FP1E5+3z3hPRo04/VgEIPiNtUPAGua lnulxhwjdIEHrIEbtxuiIgEOs2Pfb94=
X-Google-Smtp-Source: ALg8bN4gzNPENszbS4DJds7wpFflossn2Q0/Td56ZNsDBZZlKNvbl2C5BrYdjVrLtGApad2mEAgOTg==
X-Received: by 2002:a1c:b456:: with SMTP id d83mr25902418wmf.115.1546019425488; Fri, 28 Dec 2018 09:50:25 -0800 (PST)
Received: from guest2s-mbp.lan ( []) by with ESMTPSA id a18sm43101999wrp.13.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Dec 2018 09:50:24 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Neil Madden <>
In-Reply-To: <>
Date: Fri, 28 Dec 2018 17:50:23 +0000
Cc: oauth <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Brian Campbell <>
X-Mailer: Apple Mail (2.3445.102.3)
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: Fri, 28 Dec 2018 17:50:32 -0000

On the assumption that this is likely to be a requirement from customers, I’d be in favour of a new server metadata field. My favourite bikeshed colour would be:


On another metadata-related note, given that the additional security of certificate-bound access tokens vanishes if the resource server doesn’t understand and enforce the certificate-binding associated with the access token, is there a general need for a client to be able to discover if any given RS does actually support this? Otherwise the whole scheme “fails open” in that the access token silently degrades to a normal bearer token. Or do we consider it unlikely that an RS is going to accept a TLS client certificate without supporting this?

— 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