Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authorisation endpoint should use MTLS. #31

Closed
ajmcmiddlin opened this issue Dec 12, 2018 · 4 comments
Closed

Authorisation endpoint should use MTLS. #31

ajmcmiddlin opened this issue Dec 12, 2018 · 4 comments
Labels
feedback wontfix

Comments

@ajmcmiddlin
Copy link

@ajmcmiddlin ajmcmiddlin commented Dec 12, 2018

§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 lukepopp added the feedback label Dec 14, 2018
@lukepopp
Copy link
Contributor

@lukepopp lukepopp commented Dec 14, 2018

@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
Copy link
Author

@ajmcmiddlin ajmcmiddlin commented Dec 14, 2018

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
Copy link
Contributor

@lukepopp lukepopp commented Dec 14, 2018

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.

@lukepopp lukepopp added the wontfix label Dec 14, 2018
@TakahikoKawasaki
Copy link

@TakahikoKawasaki TakahikoKawasaki commented Jan 17, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feedback wontfix
Development

No branches or pull requests

3 participants