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 <jric...@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 <da...@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....@dmarc.ietf.org> wrote:
>>>
>>> Yeah, probably.
>>>
>>> On Sat, Feb 2, 2019 at 12:39 AM Neil Madden <neil.mad...@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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
