<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content

Understanding Certificate Validity and Rotation in Okta JWT-Based Authentication

Okta Classic Engine
Okta Identity Engine
Administration

Overview

When using a Private Key JSON Web Token (JWT) for OAuth 2.0 client authentication, client applications digitally sign authentication assertions using a private key. Okta verifies these tokens using the matching public key published by the client. Certificate ownership, procurement, and key rotation behavior differ between dynamic JSON Web Key Sets (JWKS) URLs and static public keys.

Applies To

  • Okta Identity Engine (OIE)
  • Okta Classic Engine
  • OpenID Connect (OIDC) and OAuth 2.0 Applications
  • Client Authentication Method: Private Key JWT (private_key_jwt)
  • JSON Web Key Sets (JWKS) and Public Key Management

Solution

Who owns and manages the signing certificates in a private key JWT flow?

In a private_key_jwt authentication flow, the external client application generates, owns, and protects the private key. The external client uses this key to sign JWT assertions sent to Okta. Okta acts as the authorization server and requires the public key of the client to validate the JWT signature. Okta does not generate or provide signing certificates for the client to use in client assertion signing.

 

The Configured Client Authentication Method Determines the Key Rotation Behavior

The client authentication method selected in the Okta Admin Console determines whether administrative action is required when an external signing certificate expires.

 

How does dynamic key rotation work with a configured JWKS URL?

When configured to use a JWKS URL, Okta queries the remote JWKS endpoint URL dynamically and caches the public keys according to standard HTTP caching and key ID (kid) lookups. Okta requires no action as long as the JWKS endpoint URL remains unchanged. The external client must generate a renewed key pair, publish the new public key or certificate to the existing JWKS URL, and begin signing with the corresponding new key ID (kid). Okta automatically retrieves the updated public key from the endpoint.

 

What steps are required for static key management when a certificate expires?

When configured to save keys or upload a certificate, an administrator manually uploads a public X.509 certificate (.pem or .crt) or public key into Okta during initial setup. Okta does not make outbound calls to any URL for key discovery. Prior to the expiration date, obtain the renewed public certificate from the external client. Navigate to the target application in the Okta Admin Console and replace the existing public key or certificate with the renewed certificate under the client authentication settings.

  1. Navigate to Applications > Applications.
  2. Select the target application.
  3. Select the General tab.
  4. Go to the Client Authentication section.
  5. Add or replace the existing public key or certificate with the renewed certificate.

 

Related References

Recommended content

Loading
Understanding Certificate Validity and Rotation in Okta JWT-Based Authentication | Okta Support