Support for additional client authentication methods at external IdP

Feature: We need Auth0 to support more authentication methods for an external IdP with OIDC/OAuth
Description: One of the identity providers we are using for authentication are depreciating authentication with secrets, and we need to support one of the following:

Shall support client authentication using either:

  • private_key_jwt ”, as described by OpenID Connect for interactive sessions.
  • Client Assertions as described by RFC 7521 and RFC7523.
  • Mutual-TLS for OAuth Client Authentication as described by RFC 8705 . (This is not supported by HelseID yet)

I found a feature request for mTLS when calling auth0, but no request for other methods when using an external IdP.

Use-case: We are building applications for healthcare providers in the nordics, and need to be conformant to the national identity providers for healthcare professionals, and also citizens.

Hey there!

Thanks for creating this feedback card. Let’s see who else will be interested in such improvement!

1 Like


We are in the same situation, developing practice management systems in the nordics and wholeheartedly support this feature request. It’s actually make or break for if we can use auth0 at all.



We are in the same situation having strict regulatory requirements, what is the conclusion / advice on this.


We also need this in regards to implementing i4trust’s idp solution as a third party IDP. This is needed in the EU for example.

We also need support for mTLS on the “token” endpoint in order to integrate with ADP as the IdP.

In addition, they don’t support well-known configuration or jwks endpoints, so we would like these to be optional.

Cześć @konrad.sopala,
Any updates from Auth0 whether there’s a plan to support Mutual TLS Client Authentication? We need to advise our technology partners if they need to start planning for an alternative solution or not.

How is it that the Okta product supports some/all of this whereas auth0 does not – even though they are from the same company and these are literally standard features (ones that I’d expect any commercial OAuth2 provider to support).