SSO login mints an OpenMetadata JWT whose lifetime comes from oidcConfiguration instead of the IdP

Component: openmetadata-service — Security / OIDC Type: Design concern Affected versions: current main

Summary

After an OIDC SSO login, OpenMetadata issues its own JWT and takes that token's lifetime from authenticationConfiguration.oidcConfiguration.tokenValidity — an operator-editable setting — rather than deriving it from the token the identity provider issued. The same pattern applies to maxAge and to session expiry.

This means the IdP's own token lifetime and revocation window are not what governs an OpenMetadata session. An operator can configure a validity longer than the IdP intends, and shortening the lifetime at the IdP has no effect on sessions OpenMetadata has already minted.

Where

• openmetadata-service/src/main/java/org/openmetadata/service/security/AuthenticationCodeFlowHandler.java:263 reads authenticationConfiguration.getOidcConfiguration().getTokenValidity(); :269 resolves it via TokenValidityResolver.resolveOrDefault(...) into the issued token's lifetime; :270 reads getMaxAge().
• openmetadata-service/src/main/java/org/openmetadata/service/security/session/SessionTimeoutResolver.java:20 falls back to oidcConfiguration.getSessionExpiry().
• openmetadata-service/src/main/java/org/openmetadata/service/security/TokenValidityResolver.java documents the design directly: "Resolves the lifetime of the JWT that OpenMetadata issues for itself after an SSO login. Both the OIDC and SAML configurations persist this as a user-editable value."

Relationship to existing work

#33172 (Fixes #30304) added TokenValidityResolver to stop a non-positive tokenValidity minting zero-lifetime tokens. That guarded the value; it did not revisit whether OpenMetadata should be setting this expiry itself for OIDC providers. This issue is about the latter.

Questions to settle

1. For OIDC, should the issued token's lifetime be derived from the IdP's token/exp rather than from configuration — and if so, should oidcConfiguration.tokenValidity become an upper bound, or be deprecated for OIDC entirely?
2. Same question for sessionExpiry and maxAge.
3. SAML persists an equivalent value (samlConfiguration.security.tokenValidity). Should it follow the same rule, or does the absence of a refresh-token equivalent justify different handling?
4. If tokenValidity is deprecated for OIDC, what is the migration path for instances that currently rely on it?

Context

Raised by @harshach in review of #33446, which does not touch this code path — filing separately so that PR stays scoped to the SAML certificate fix it addresses.