Problem Statement

In ODC, a Client Secret is required in virtually every scenario where an app communicates with external systems or calls ODC Management APIs programmatically:

• UsersManagement (Forge) → ODC User & Access Management API
• External IdP integration (OIDC) → Azure AD, Okta, etc.
• ODC REST API calls → Portfolio API, and others
• External service integrations → Salesforce, MS Graph, etc.

The current behavior is that Client Secrets expire every 90 days by default (maximum 2 years), and renewal is only possible manually through the ODC Portal.

Root Cause of the Issue

This is not merely an inconvenience — it is a structural constraint that breaks the promise of full automation in ODC-based services.

Here is why:

① No programmatic renewal path exists

There is currently no Management API endpoint to rotate or renew a Client Secret. This means that no matter how well-automated your app logic is (e.g., a Timer-based user management flow), the secret renewal step always requires direct developer intervention.

② Expiry creates operational risk at scale

In production SaaS or B2C environments running on ODC, a missed secret expiry means:

• All features depending on that secret stop working silently or with cryptic errors
• End-users are impacted before the team is even aware
• Recovery requires Portal access by a developer with the right permissions — not something an end-user Admin can resolve

③ The expiry cycle creates recurring developer toil

Even with the maximum 2-year expiry configured, and even with calendar reminders or monitoring in place, this is manual, recurring, high-risk maintenance. It runs counter to the Low-Code philosophy of ODC: reducing developer toil and enabling reliable, autonomous operation.

Requested Feature(s)

Please implement one or more of the following:

Option A — Programmatic Secret Renewal via Management API

Add a Management API endpoint that allows an authorized app to rotate or renew a Client Secret before expiry. This would enable a Timer-based auto-renewal flow entirely within ODC, with zero developer intervention.

POST /api/v1/clients/{clientId}/secrets/rotate→ Returns: new_secret, valid_from, expires_at

Option B — No-Expiry Secret Option

Allow trusted, internal service accounts to opt into a non-expiring Client Secret, similar to how other platforms (e.g., Azure App Registrations, AWS IAM long-term credentials) provide this option with explicit acknowledgment of the security trade-off.

Option C — Secret Rotation with Overlap Window

Support a dual-secret validity window during rotation — where both the old and new secrets remain valid for a configurable overlap period (e.g., 24–72 hours). This enables zero-downtime secret rotation in production environments.