The structural problem
Neither SAML 2.0 nor OpenID Connect has a change notification mechanism. An identity provider publishes a metadata document; relying parties are expected to read it. In practice most integrations read it exactly once, at setup, and copy the values into a configuration store.
From that moment the two sides can drift apart with no signal at all. The first indication that something changed is a user who cannot sign in.
In a multi-tenant B2B product this compounds: every customer has their own IdP, on their own rotation schedule, changing at times you do not control and are not told about.
What changes, and what it breaks
| Field | What happens when it changes | Result |
|---|---|---|
| Signing certificate | Rotated, expired, or newly added | Signature validation fails |
entityID |
Renamed during a migration | Issuer mismatch on every assertion |
| SSO endpoint URL | Moved to a new host or path | Requests go to a dead endpoint |
| Endpoint binding | Redirect swapped for POST | Requests rejected as malformed |
validUntil |
Document lapses | Strict consumers reject the metadata itself |
| NameID format | Changed identifier format | Users provision as duplicates |
OIDC jwks_uri keys |
Key IDs rotated | Token validation fails |
OIDC issuer |
Changed | Every token rejected |
Certificate rotation is the most frequent by a wide margin. Endpoint changes are rarer and harder to diagnose, because the failure looks nothing like a certificate problem.
Why “we’ll just fetch it live” is not the answer
Fetching metadata on every authentication makes the IdP a hard dependency of every login and moves the failure rather than removing it. Most implementations therefore cache, and caching is what allows the drift.
The workable pattern is to read the document on a schedule, compare it against the last known state, and alert a human when a watched field moves — separately from the authentication path.
What is worth watching
Watching the whole document produces noise: whitespace, attribute order and comments all change without meaning anything. A useful comparison is restricted to fields whose change has a consequence:
- The set of signing certificate fingerprints, with their validity windows
entityIDor OIDCissuer- SSO and SLO endpoint URLs, and their bindings
- Document
validUntil - OIDC key IDs and discovery endpoints
A change in any of those is worth an alert. A change outside them is not.
Reading the current state
The free checker shows the current value of each of those fields for any public metadata URL, along with a content hash over exactly that set — the same projection scheduled monitoring compares between scans.