Zero Trust Begins with Zero Shared Secrets

Using a client secret to authenticate an application is a bit like writing your password on a sticky note and handing it to someone else. It works, but only if everyone who touches it is careful, no one ever copies it, and you remember to change it before anything goes wrong.

For years, that’s how systems authenticated with OpenID Connect (OIDC): using long-lived, reusable secrets shared between clients and identity providers (IdPs). But in today’s threat landscape—where secrets get logged, leaked, and left behind—that model just isn’t good enough.

Now, with Private Key JWT Client Authentication for OIDC and Okta Enterprise Connections, available in Early Access, Auth0 offers a more secure, standards-based alternative. Instead of passing shared secrets between systems, Auth0 signs short-lived JWTs with a private key on a per-request basis, enabling signature-based trust, built-in expiration, and no shared credentials.

Combined with existing support for Private Key JWT authentication from applications to Auth0, this release completes the picture: both direct login with Auth0 as the IdP and federated login flows can now have security without any client secrets.

Why Client Secrets No Longer Cut It

Client secrets have been a default mechanism in OIDC authentication flows for years, but they come with serious limitations:

• They’re static: Secrets don’t expire unless someone rotates them manually.
• They’re symmetric: Both the client and the IdP must store the same secret.
• They’re hard to secure at scale: Especially in distributed architectures or across multi-tenant environments.

This model assumes a shared secret can be protected forever. But in practice, secrets leak through misconfigured pipelines, exposed logs, stale repositories, or over-permissioned vaults.

Private Key JWT Client Authentication addresses these limitations, specifically in the context of enterprise federated identity flows.

What Private Key JWT Client Authentication Enables for Enterprise Connections

This release introduces support for JWT-based authentication from Auth0 to upstream identity providers in OIDC and Okta Workforce enterprise connections.

Instead of storing and sending a client_secret, Auth0 now enables developers to perform client authentication using a client assertion JWT signed with a per-connection private key. The upstream IdP verifies it using the corresponding public key.

Each JWT:

• Is generated dynamically per token request
• Expires after 60 seconds or less
• Includes a jti claim for replay protection
• Is signed with a private key managed by Auth0

No static credentials. No shared secrets. No reuse.

This capability aligns with RFC 7523 and is compatible with identity providers that support private_key_jwt as their token endpoint authentication method.

A Fully Secretless Authentication Flow

This release introduces support for asymmetric JWT-based client authentication from Auth0 to upstream identity providers, complementing the existing Private Key JWT support for authenticating applications to Auth0. While each mechanism applies to a different type of login flow - direct (app → Auth0) versus federated (Auth0 → IdP) - together they let organizations eliminate client secrets on both sides of the authentication process. Whether between the app and Auth0 or between Auth0 and the enterprise IdP, authentication can now rely entirely on signed, short-lived JWTs.

Here’s a side-by-side comparison of how the two mechanisms work:

How It Works

Here’s what changes when you use Private Key JWT Client Authentication for enterprise connections:

1. A user authenticates via an enterprise IdP (e.g., Okta, Ping, ForgeRock).
2. The IdP returns an authorization code to Auth0.
3. Auth0 generates a signed JWT using the connection’s private key.
4. Auth0 sends the JWT (as client_assertion) to the IdP’s token endpoint.
5. The IdP verifies the signature using the registered public key (JWKS URI or inline).
6. Tokens are issued - no shared secret ever exchanged.

This is now available in Early Access for any custom OIDC or Okta Workforce connection configured to use Private Key JWT Client Authentication.

Why Enterprises are Making the Switch

Asymmetric Security and No Credential Sharing
JWTs are signed and short-lived; secrets never leave your environment. Public keys are published via JWKS, and there’s nothing to store, rotate, or accidentally leak.

Compliance with High-Security IdPs
Some IdPs require signed JWTs — not secrets — for authorization code exchange. This feature facilitates integrations with these IdPs, enabling developers to work within policy or compliance constraints.

Secure, Auditable Key Rotation
Keys are generated and stored more securely by Auth0 per connection. Rotation is supported through the Dashboard or Management API, and Auth0 supports multi-key publishing to avoid downtime during transitions.

Learn More and Get Started

To learn more about how to configure Private Key JWT Client Authentication for enterprise connections, check out our Early Access documentation.