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
<bcampbell=40pingidentity....@dmarc.ietf.org> 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@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
