Summary Support for concurrent (overlapping) client secrets with configurable time-to-live (TTL) to enable automated, zero-downtime secret rotation. Problem When rotating a Port client secret, the old secret is immediately invalidated upon replacement. In distributed systems, consuming services need time to pick up the new secret value. During this propagation window, services still using the old secret experience authentication failures, causing downtime or errors. Currently, the same secret name cannot hold two valid values simultaneously, and there is no built-in mechanism to set an expiry/lifetime on a secret. While a custom automation can partially work around this, the lack of native support makes automated rotation fragile and error-prone. Proposed Solution Concurrent secrets: Allow at least two valid secrets to coexist for the same credential (e.g., a "primary" and "secondary" key pattern, similar to Azure AD app registrations or AWS IAM access keys). Both secrets should be accepted for authentication until the older one is explicitly revoked or expires. Secret TTL / expiry: Allow an optional time-to-live to be set when creating or rotating a secret. Once the TTL elapses, the secret is automatically invalidated. This enables a "create new → wait for propagation → old expires" workflow without manual cleanup. Rotation API: Expose a secret rotation endpoint (or extend the existing secrets API) that creates a new secret while keeping the previous one valid for a configurable grace period. This would integrate naturally with self-service actions for automated rotation schedules. Use Case As a platform team operating Port integrations across multiple Kubernetes services (Ocean integrations, CronJobs, Lambda functions), we want to automate client secret rotation on a regular cadence via a self-service action. The rotation flow would be: Generate a new secret (old secret remains valid) Propagate the new secret to consuming services (via K8s secrets, SSM parameters, etc.) Old secret expires after a configured grace period (e.g., 24 hours) Without concurrent secret support and TTL, there is always a window where some consumers hold a stale secret, resulting in failed API calls. Alternatives Considered Custom automation with rapid propagation: Rotate the secret and immediately push to all consumers. This is brittle — any delay or failure in propagation causes outages. - Scheduled maintenance window: Coordinate rotation during low-traffic periods. This doesn't scale and defeats the purpose of automation.
