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

I’m less and less convinced that a redirect is the best way to do this.

I was reading the WHATWG Fetch spec yesterday, in particular the entries about CORS, and realised that for cross-origin requests TLS client certificates are treated as credentials just like cookies: https://fetch.spec.whatwg.org/#credentials

    Credentials are HTTP cookies, TLS client certificates, and authentication entries (for HTTP authentication)

So assuming that web browser clients calling the token endpoint will most likely be calling cross-origin, then it seems that client certificates won’t be sent anyway unless Access-Control-Allow-Credentials: true is returned from the preflight request. Given that calls to the token endpoint shouldn’t generally require cookies, then it seems likely that you can just *not* allow credentials in the CORS response and therefore not have any problem with prompting users for certificates. (Note that you can still manually set the Authorization header without ACAC set to true, you just have to whitelist that header in the AC-Allowed-Headers response).

I haven’t got time to test it myself right now, but if so that seems like it side-steps the issue pretty neatly. Configure the token endpoint to ask for, but not require, client certs, and then make sure you don’t return Access-Control-Allow-Credentials: true on CORS preflight requests to that endpoint.

— Neil

> On 5 Feb 2019, at 15:21, Justin Richer <jricher@mit.edu> wrote:
> 
> +1 to David. If it’s a redirect, 307 is more appropriate. It’s up to the AS to decide if the client should do MTLS or not, if there’s an option.
> 
> — Justin
> 
>> On Feb 4, 2019, at 12:17 PM, David Waite <david@alkaline-solutions.com> wrote:
>> 
>> My understanding is that a permanent redirect would be telling the client (and any other clients getting cached results from an intermediary) to now stop using the original endpoint in perpetuity for all cases. I don’t think that is appropriate (in the general case) for an endpoint with request processing business logic behind it, since that logic may change over time.
>> 
>> -DW
>> 
>>> On Feb 4, 2019, at 6:28 AM, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:
>>> 
>>> Yeah, probably. 
>>> 
>>> On Sat, Feb 2, 2019 at 12:39 AM Neil Madden <neil.madden@forgerock.com> wrote:
>>> 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
>> 
>> _______________________________________________
>> 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