A common question regarding OpenID Connect (OIDC) and OAuth 2.0 applications in Okta is whether the generated client secrets have a built-in expiration date. Unlike SAML certificates or API tokens, Okta client secrets do not have an automated expiration mechanism, which requires administrators to manage their lifecycle manually to maintain security compliance.
- OpenID Connect (OIDC)
- OAuth 2.0
- Client Secrets
- Okta Classic Engine
- Okta Identity Engine (OIE)
By design, Okta client secrets remain valid indefinitely. They do not possess a defined lifespan or idle timeout. A secret only becomes invalid if it is manually rotated/deleted within the Okta Admin Console or if the application itself is deleted.
Because client secrets do not expire, it is a best practice to implement a manual rotation schedule to mitigate the risk of secret compromise. To manage or rotate a client secret, follow these steps:
- In the Okta Admin Console, navigate to Applications > Applications.
- Select the specific OIDC/OAuth 2.0 application.
- Go to the General tab.
- Locate the Client Credentials section.
- To generate a new secret, click Generate new secret.
- NOTE: When a new secret is generated, the previous one remains active for a short period. This "grace period" allows for zero-downtime updates so the application code can be updated with the new secret before deleting the old one.
- Once the new secret is deployed in the environment, click the Deactivate or Delete icon next to the old secret to ensure it can no longer be used.
Key Security Considerations
- No Automatic Expiry: Because secrets do not expire, they can remain active for years. Security compliance often requires manual rotation to mitigate the risk of a compromised secret.
- Secret Rotation: A new secret can be generated at any time. When a new secret is generated, the previous one remains active for a short period (or until manually deleted) to allow for zero-downtime updates in the application code.
- Client Secret vs. Private Key JWT: For higher security requirements, consider using Private Key JWT instead of a client secret. This enables expiration management via the public/private key pair metadata.
