Every SAML connection depends on a signing certificate that was pasted into a form at setup and then forgotten. Certificates have expiry dates, providers roll them on their own schedule, and the failure mode is total: every sign-in for that customer fails at once, with an error that says the signature did not verify.
The same problem exists for OIDC, in a gentler form. Providers publish their keys at a well-known endpoint and rotate them regularly, so the question is not whether you noticed but whether your cache did.
Hold more than one certificate
A connection that stores exactly one trusted certificate cannot be rotated without downtime. There is no instant at which both the old and the new one are correct, so somebody has to paste the new value at exactly the moment the provider starts using it, across a time zone boundary, on a working day.
Storing a set instead removes the coordination entirely. Accept a signature from any certificate in the set, add the new one whenever the customer supplies it, and remove the old one after it stops appearing. The overlap costs nothing and turns a scheduled outage into a configuration change nobody has to be awake for.
One trusted certificate means rotation requires two people to act in the same minute. A set means neither has to.
Prefer the URL to the file
Most providers publish a federation metadata document at a stable URL containing the issuer, the sign-in endpoint and the current certificates. If a connection is configured with that URL rather than an uploaded file, rotation becomes something you observe rather than something you are told about.
Fetch it on a schedule, and treat the result carefully. A metadata document that fails to load is not a reason to drop the certificates you already trust; keep serving from the last known good copy and raise an alert. A document that loads but is unsigned, or signed by something you do not recognise, is worse than no document at all.
- Refresh metadata on a schedule and on demand, never only at setup
- Never let a failed fetch narrow the trusted set; fail open on the old copy, alert loudly
- Verify the metadata document's own signature where the provider signs it
- Cache OIDC keys with a bounded lifetime, and refetch on an unknown key identifier — once, with a rate limit
Tell somebody before it breaks
The cheapest reliability work in this whole area is a job that reads the expiry date of every certificate you hold and raises it when the horizon gets short. Sixty days, thirty days, seven days, and the message should reach the customer's administrator as well as your support team, because they are the only ones who can act.
Include what to do in the message. An administrator who receives a warning naming the connection, the expiry date and a link to the setup screen will handle it in ten minutes. One who receives a signature verification error at nine on a Tuesday will open a ticket and wait.
Everything here, already built
Sign-in, enterprise SSO, directory provisioning, roles and an audit trail behind one API. Start with the quickstart and have a working sign-in this afternoon.