feat(httpd): handle SIGHUP to permit hot reload oidc secret from clientSecretFile

[NikitaCOEUR]

Checklist for Pull Requests

• Have you signed the Contributor License Agreement?

---

Description :

This pull request adds the ability to hot reload OIDC client secrets from file using SIGHUP signal (Unix) or 'paramchange' service control on Windows.

Key changes:

• Add ReloadOIDC() function to reload OIDC secrets for all HTTP servers
• Add ReloadSecret() method to OIDC struct for atomic secret reload
• Integrate OIDC reload into existing signal handlers
• Thread-safe server tracking with httpServers slice and mutex
• Comprehensive test coverage for all reload scenarios

Important limitations:
⚠️ Hot reload is ONLY functional for secrets defined in clientSecretFile
⚠️ Direct clientSecret in config cannot be hot reloaded

[CLAassistant]

All committers have signed the CLA.

[tecosaur]

Given that OIDC secrets are generally not expected to change often (or at all), I'd be interested to hear the motivation for this change.

[NikitaCOEUR]

Given that OIDC secrets are generally not expected to change often (or at all), I'd be interested to hear the motivation for this change.

In the case of Microsoft Entra ID (formerly Azure AD), OIDC client secrets do have enforced expiration policies. Until 2021 it was possible to create “never expiring” secrets (often represented as 99-year values), but Microsoft has since deprecated that option in the portal.

When creating a client secret through the Entra admin portal, the maximum selectable lifetime is 24 months (Microsoft 365 Dev Blog).

While it’s technically still possible to generate longer-lived secrets using PowerShell or Microsoft Graph API by setting a far-future endDateTime, Microsoft’s current guidance is to avoid this and instead implement regular rotation.

The recommended best practice is to rotate secrets every 6–12 months and, where possible, move to Managed Identities or store credentials in Azure Key Vault to automate rotation.

So while in some OIDC providers client secrets can effectively remain static, in Entra ID they are explicitly time-bounded (max 2 years via the portal). That’s the motivation for ensuring our implementation can handle secret renewal gracefully, rather than assuming immutability.

[tecosaur]

I see, thanks for that elaboration. I can't help but wonder if given that frequency (a few times a year), why switching out the secrets and restarting the sftpgo process isn't good enough?

[NikitaCOEUR]

I see, thanks for that elaboration. I can't help but wonder if given that frequency (a few times a year), why switching out the secrets and restarting the sftpgo process isn't good enough?

You're right — in principle, rotating the secret manually and restarting the sftpgo process a few times a year wouldn’t be a major issue.

The main reason I’m aiming for this change is to enable fully automated secret renewal without service impact. If a restart is required every time, it effectively means:

• Scheduling a maintenance window,

• Forcing active connections to drop, and

• Making it harder to increase the rotation frequency beyond the minimum (e.g. 6–12 months).

By avoiding restarts and disconnections, we can rotate secrets transparently in the background, which aligns better with security best practices and lets us rotate more often without operational overhead