Support client secret rotation with grace period

[ThaminduDilshan]

What problem are we solving?

Currently, Thunder supports client secret regeneration via console UI and API, but only stores a single active secret per application. When a secret is rotated, the previous secret becomes immediately invalid, breaking any client still using the old credential. There's no grace period or support for multiple active secrets during the transition.

This forces clients to update their credentials immediately, which isn't always feasible in distributed systems and creates operational friction.

Who are we solving this for?

API administrators and application developers who need to:

• Rotate secrets without breaking active client connections
• Manage credential lifecycle safely in production environments
• Audit when and how secrets were rotated

Why should we solve this now?

Proper secret rotation is a security best practice. Production systems need:

• A grace period to update client credentials
• Audit trails for compliance
• Ability to hold multiple secrets during transition
• Automatic expiration of old secrets

Proposed Solution

Implement backend support for secret rotation with:

1. Multiple active secrets: Store current and previous secret, both valid during grace period
2. Lifecycle tracking: Add created_at, expires_at, and status fields per secret
3. Dedicated rotation API: New endpoint POST /applications/{id}/secrets/regenerate with optional grace period parameter
4. Automatic expiration: Clean up expired secrets based on configurable policy
5. Audit logging: Track rotation history (timestamp, operator)

The UI already has regenerate capability; this focuses on backend support for proper credential lifecycle management.

Alternatives

No response