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

2019-02-01 Thread Neil Madden
If we go down the 307 route, shouldn’t it rather be a 308 (permanent) redirect? It seems unnecessary for the client to keep trying the original endpoint or have to remember cache-control/expires timeouts. — Neil > On 2 Feb 2019, at 00:03, Richard Backman, Annabelle > wrote: > > Confusion fr

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

2019-02-01 Thread Phil Hunt
Brian, Thanks for clarifying. Given the browser uncertainty that happens with optional configs and browsers, I agree with your suggestion of using ‘mtls_endpoints’. I’m expecting this will be a big deal as we migrate apps and clients. We have to make sure old clients keep working and don’t do u

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

2019-02-01 Thread Brian Campbell
Yes client certificate authen can be made optional. In the optional case the server still sends the CertificateRequest message during the handshake which efficiently asks the client to present a cert. The client send a cert or not at that point. In the optional case, the server will continue with t

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

2019-02-01 Thread Brian Campbell
It doesn't seem like that confusing or large of a change to me - if the client is doing MTLS and the given endpoint is present in `mtls_endpoints`, then it uses that one. Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a

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

2019-02-01 Thread Phil Hunt
Brian, Let me turn this around. Is it possible for a single endpoint to have MTLS clients (mutual auth) and bearer clients (server auth TLS)? I had thought that client certificate authen can be made optional, but I must confess I’m confused as to how optionality works in TLS when it comes to

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

2019-02-01 Thread Brian Campbell
I guess I'm not clear what you are driving at. On Fri, Feb 1, 2019 at 2:32 PM Phil Hunt wrote: > That way works. But one of the modes on most tls terminators is client > cert optional. > > This works ok when you want dual mode to support bearer and mtls for apps > (e.g. mobile) because the clien

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

2019-02-01 Thread Phil Hunt
That way works. But one of the modes on most tls terminators is client cert optional. This works ok when you want dual mode to support bearer and mtls for apps (e.g. mobile) because the client will decide to use MTLS. With browsers, they only use it if forced. Phil Oracle Corporation, Cloud

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

2019-02-01 Thread Brian Campbell
Yes, that would work. On Fri, Feb 1, 2019 at 2:28 PM George Fletcher wrote: > What if the AS wants to ONLY support MTLS connections. Does it not specify > the optional "mtls_endpoints" and just use the normal metadata values? > > On 1/15/19 8:48 AM, Brian Campbell wrote: > > It would definitely

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

2019-02-01 Thread George Fletcher
What if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoints" and just use the normal metadata values? On 1/15/19 8:48 AM, Brian Campbell wrote: It would definitely be optional, apologies if that wasn't made clear. It'd be something to the effect of o

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

2019-02-01 Thread Brian Campbell
The server has to ask during the handshake for a client to send a cert. On Fri, Feb 1, 2019 at 2:12 PM Phil Hunt wrote: > If a client attempts to force mtls would typical tls terminators accept it > enough to redirect? > > My worry is how optionality works in browsers. It seems like they have to

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

2019-02-01 Thread Phil Hunt
If a client attempts to force mtls would typical tls terminators accept it enough to redirect? My worry is how optionality works in browsers. It seems like they have to hit an mtls required endpoint before they reliably use a client cert. Phil > On Feb 1, 2019, at 12:56 PM, Brian Campbell >

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

2019-02-01 Thread Brian Campbell
It would be more a client having reached a non-MTLS endpoint and is 307'd to an MTLS enabled endpoint. On Fri, Feb 1, 2019 at 1:40 PM Phil Hunt wrote: > I was a bit confused by how the 307 would work. > > To confirm, Is the client having reached an MTLS optional endpoint being > redirected to an

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

2019-02-01 Thread Phil Hunt
I was a bit confused by how the 307 would work. To confirm, Is the client having reached an MTLS optional endpoint being redirected to an MTLS mandatory endpoint if the AT (or a cookie) is detected to have a “cnf” claim in order to make the browser invoke MTLS? Phil Oracle Corporation, Cloud S

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

2019-02-01 Thread Brian Campbell
I'm finally getting around to working on the document updates (there's quite a few things that came out of AD review too). As far as the issue in this thread goes though, I'm leaning towards adding "mtls_endpoints" as a new metadata parameter. Maybe mention that a 307 might happen but it'd be more