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
<https://tools.ietf.org/html/draft-ietf-oauth-mtls-12> 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
