Closed cruskit closed 2 years ago
The client is behaving correctly and this exact behaviour is also certified using the certification suite.
The PAR endpoint is not issuing tokens, ergo the tls_client_certificate_bound_access_tokens
has no effect on the behaviour. And you're using private_key_jwt
which, likewise, does not preclude the use of an mtls_endpoint_aliases
listed endpoint.
What issue are you facing exactly?
cc @jogu
In our ecosytem we want to require the client to use the MTLS endpoint when performing the PAR. I can't work out / understand the configuration required so that the openid-client will use the MTLS version of the PAR endpoint - it always seems to call the non-mtls version of the endpoint.
Paul,
Filip is correct in his implementation (I’ve never know him not to be). Par is not a token issuing endpoint and so that flag isn’t required. Technically par also doesn’t require the use of mtls when using private key jwt so this behaviour is correct.
I believe the correct behaviour is if a bank wants mtls to enforced on this endpoint is to require it on the standard endpoint.
Now this is where it gets potentially more complicated, @jogu. There’s nothing in the spec that says a bank can’t require mtls for this endpoint but when I last tried it the conformance suite refused to honour the mtls requirement on the non mtls endpoint key and failed.
So the question is, should the client always utilise the mtls endpoints even if using private_key_jwt or should the conformance suite honour a requirement to use mtls if it's not strictly required on the standard par endpoint.
RB
In our ecosystem we want to require the client to use the MTLS endpoint when performing the PAR.
You'll need to use one the MTLS client authentication methods. Otherwise there's no need to use the MTLS-specific PAR endpoint.
Or you can just not have aliases for this endpoint altogether. Providing the mtls specific request options (key, cert, etc) will then be honoured.
I've labeled this as https://github.com/panva/node-openid-client/labels/wontfix, despite there being nothing to "fix" since this behaviour is expected.
If ecosystems want to do wonky stuff like requiring MTLS always despite there being no reason for it (issuing tokens, client auth), they shall not use an aliased endpoint.
Thanks Filip and Ralph for the feedback.
Describe the bug When trying to send a Pushed Authorization Request to a PAR endpoint that uses private_key_jwt authentication and is also requires MTLS, the openid-client will always select the non-mtls version of the endpoint.
In
client.js
,pushedAuthorizationRequest
callsauthenticatedPost
as follows - notepushed_authorization_request
passed asendpoint
value:Then in
helpers/client.js:authenticatedPost()
, the check is as follows:For the mTLS check, if using private_key_jwt for authentication, the first condition will be false. For a PAR the second condition will always be false as
pushed_authorization_request
was passed in as theendpoint
value which can never=== 'token'
. As a result mTLS can never be true for a PAR using private_key_jwt.Suggest the check may need to be along lines of:
To Reproduce Issuer and Client configuration: (inline or gist) - Don't forget to redact your secrets.
// Issuer configuration (issuer.metadata) and how it is constructed (discovery or manual?) Discovery via .well-known:
// Client configuration (client.metadata) and how it is constructed (fromUri or manual?) Manual:
Steps to reproduce the behaviour:
private_key_jwt
, andtls_client_certificate_bound_access_tokens
=true
Expected behaviour With token_endpoint_auth_method set to
private_key_jwt
andtls_client_certificate_bound_access_tokens
=true
it should use the MTLS PAR endpointEnvironment:
Additional context Add any other context about the problem here.