search

ConsumerDataStandardsAustralia / infosec

Work space for the consumer data right information security profile development in Australia
MIT License
16 stars 5 forks source link

Authorisation endpoint should use MTLS. #31

Closed ajmcmiddlin closed 5 years ago

ajmcmiddlin commented 5 years ago

§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.

  1. shall only issue authorization code, access token, and refresh token that are holder of key bound;
  2. 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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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