Fixes #30304: Prevent zero-lifetime OIDC login tokens

[harshach]

Describe your changes:

Fixes #30304

I fixed OIDC logins that loop forever when a persisted OpenMetadata access-token validity is zero, causing every newly issued JWT to have exp == iat.

Type of change:

• Bug fix

High-level design:

OIDC token validity remains a persisted OpenMetadata JWT setting, but its schema now defaults to 3600 seconds and rejects values below 1. Configuration writes enforce the same constraint, runtime protects deployments with corrupt persisted data by falling back to 3600 seconds, and idempotent MySQL and PostgreSQL 2.0.2 migrations repair existing non-positive values. Provider-token inheritance was not used because OpenMetadata signs its own API JWT after OIDC authentication; the generated UI schema and provider guidance now make that ownership explicit.

Tests:

Use cases covered

• Persisted zero or negative token validity is migrated to 3600 during a 2.0.2 upgrade
• Positive, missing, and unrelated settings remain unchanged
• Replaying either database migration is a no-op
• New non-positive OIDC token-validity settings are rejected
• Runtime falls back to 3600 seconds if invalid persisted data bypasses migration
• SSO form renders with the regenerated schema and corrected field guidance

Unit tests

• Added focused tests for schema validation, runtime fallback, settings validation, and migration presence
• Files: OidcTokenValidityTest.java, SystemRepositoryOidcTokenValidityTest.java, OidcTokenValiditySqlMigrationTest.java
• Java result: 9 tests passed
• OidcTokenValidity.java coverage: 100% lines, 100% branches
• UI result: 55 tests passed in SSOConfigurationForm.test.tsx
• SSO.constant.ts coverage: 100% lines, 90% branches

Backend integration tests

• Not applicable — no backend API changes

Ingestion integration tests

• Not applicable — no ingestion changes

Playwright (UI) tests

• Not applicable — this changes schema validation and explanatory copy, with the existing SSO form Jest suite covering rendering

Manual testing performed

1. Started ephemeral PostgreSQL 15 and MySQL 8.3 databases with representative openmetadata_settings rows
2. Seeded zero, negative, positive, missing, and unrelated token-validity values
3. Executed each 2.0.2 migration and verified only non-positive authentication values changed to 3600
4. Executed each migration a second time and verified no further rows changed
5. Built and ran the updated distribution in an isolated PostgreSQL/OpenSearch Docker stack
6. Verified /api/v1/auth/refresh returned a JWT with exp - iat = 3600 and that the refreshed token returned 200 from loggedInUser

UI screen recording / screenshots:

TODO: Attach a before/after screenshot of the renamed OpenMetadata Access Token Validity field before marking this PR ready for review.

Checklist:

• I have read the CONTRIBUTING document.
• My PR title is Fixes <issue-number>: <short explanation>
• My PR is linked to a GitHub issue via Fixes #<issue-number> above.
• I have commented on my code, particularly in hard-to-understand areas.
• For JSON Schema changes: I updated the migration scripts or explained why it is not needed.
• For UI changes: I attached a screen recording and/or screenshots above.
• I have added tests (unit / integration / Playwright as applicable) and listed them above.

Bug fix

• I have added a test that covers the exact scenario we are fixing.

[github-actions]

❌ PR checklist incomplete

This PR cannot be merged until the following are addressed on its linked issue:

• Issue User login fails after adding the configuration offline_access in scope for SSO OKTA #30304 is missing Shipping → Source.

The fields live on the linked issue in the Shipping project (open the issue → right sidebar → Projects). After you set them, re-run this check (or push a commit) — issue/project changes do not re-trigger it automatically.

Maintainers can bypass this check by adding the skip-pr-checks label.

[github-actions]

🔄 Playwright impact map auto-refreshed

This PR touched specs or UI source that changed the source→spec routing map. I regenerated .github/playwright/impact-map.generated.json and pushed the diff to this branch.

- source entries: 759 → 759
- 0 added, 0 removed, 6 changed spec-list

Entries whose spec list changed:
  openmetadata-ui/src/main/resources/ui/playwright/support/entity/TableClass.ts
  openmetadata-ui/src/main/resources/ui/playwright/support/fixtures/base.ts
  openmetadata-ui/src/main/resources/ui/playwright/utils/common.ts
  openmetadata-ui/src/main/resources/ui/playwright/utils/domain.ts
  openmetadata-ui/src/main/resources/ui/playwright/utils/entity.ts
  openmetadata-ui/src/main/resources/ui/playwright/utils/tier.ts

What is this file? It is the auto-generated half of Playwright's PR planner. It routes "if source X changes, run specs Y" by walking spec imports and cross-referencing getByTestId strings. Hand-authored routing in impact-map.json always wins on conflict.

What if I want to regenerate locally instead? Run this before pushing your next change to skip the bot commit:

python3 .github/scripts/generate_playwright_impact_map.py
git add .github/playwright/impact-map.generated.json
git commit --amend --no-edit  # or a separate commit

[github-actions]

Jest test Coverage

UI tests summary

Lines	Statements	Branches	Functions
	70.92% (96315/135805)	55.6% (57219/102905)	56.94% (19064/33478)

[gitar-bot]

Code Review ✅ Approved 1 resolved / 1 findings

Fixes infinite OIDC login loops caused by zero-lifetime tokens by adding schema validation, runtime fallback to 3600 seconds, and idempotent database migrations that repair corrupt persisted data. Comprehensive unit and integration tests confirm schema validation, migration safety, and runtime protection. No issues found.

✅ 1 resolved

✅ Quality: Invalid tokenValidity on save returns HTTP 500 instead of 400

📄 openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/SystemRepository.java:555-557 📄 openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/SystemRepository.java:483-495 📄 openmetadata-service/src/main/java/org/openmetadata/service/security/OidcTokenValidity.java:29-33
In prepareSettingForUpdate, OidcTokenValidity.validate() throws IllegalArgumentException for a non-positive tokenValidity, but updateSetting's catch block re-throws every Exception as CustomExceptionMessage(INTERNAL_SERVER_ERROR). Since Settings.configValue is an untyped Object, the generated @min(1) constraint does not cascade during JAX-RS @Valid validation, so an explicit tokenValidity=0 reaches this path and surfaces to the client as an HTTP 500 rather than a 400 client error, even though the dedicated validateOidcTokenValidity path already returns a clean FieldError. Consider validating token validity in prepareSettingForUpdate by returning/throwing a bad-request-mapped exception (or reusing the FieldError validation) so invalid input is reported as 400.

Options

Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source}

[sonarqubecloud]

Quality Gate passed for 'open-metadata-ui'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonarqubecloud]

Quality Gate passed for 'open-metadata-ingestion'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud