Authorisation endpoint should use MTLS.

[ajmcmiddlin]

§13.2 of version 0.0.3 of this spec says the authorisation endpoint uses TLS. I believe it should use MTLS.

FAPI part 2 §5.2.2 includes the following.

5. shall only issue authorization code, access token, and refresh token that are holder of key bound;
6. shall support [OAUTB] or [MTLS] as a holder of key mechanism;

§11.3 of version 0.0.3 of this spec forbids using OAUTB and therefore only allows MTLS to be used. As a result, for the authorization code to be holder of key bound I believe the authorisation endpoint must use MTLS.

[lukepopp]

@ajmcmiddlin The Authorisation Endpoint is browser-facing so that won't work unless client certificates are installed in each browser which is obviously not practical. For our solution, Holder of Key is aimed at ensuring that backend systems use the same certificate for API calls that was used against the Token Endpoint. If an Access Token is copied accidentally or stolen, it can't be used by itself to call APIs.

[ajmcmiddlin]

I agree. Now that I think about it MTLS is impractical as you say. How does FAPI part 2 expect authorization codes to be holder of key bound then? I feel like I'm misunderstanding what they're mandating, or it's an oversight in the spec.

[lukepopp]

Good question. You could enforce HOK where the Auth Code goes to say a device (implicit flow) which then calls the TokenEndpoint but can't see how it would work with certs and separate systems.

[TakahikoKawasaki]

FYI: I had the same interpretation as @ajmcmiddlin. See "fapi issue 202" if you are interested.