A connection that has worked for a year stops working on a Tuesday. You did not deploy. The customer insists nothing changed on their side, and they believe it, because the person who changed something is three teams away and considered it routine maintenance.
Identity provider configuration is not static, and your connection holds a copy of it. Everything below is a change somebody can make in an administrative console in under a minute, with no idea that a third-party application depends on the field they just edited.
A short taxonomy of what moves
The failures separate cleanly into two groups: changes that break sign-in loudly, and changes that let people sign in as somebody who is not quite them. The first group generates a support ticket within minutes. The second is far worse, because it can run for weeks before anybody notices duplicate accounts accumulating.
Loud failures come from the transport: an endpoint URL moved, the entity identifier was renamed during a tenant consolidation, the binding changed from POST to redirect. Quiet failures come from identity: the subject format changed, or an attribute is now emitted under a different name, or a claim that used to carry groups now carries object identifiers instead of display names.
- Entity identifier renamed — audience validation fails and every assertion is rejected
- Sign-on endpoint moved — requests go to a URL that now returns an error page
- Subject format switched from an address to an opaque identifier — everyone looks new
- Attribute or claim renamed — profiles arrive with missing names, or missing groups
- Tenant migrated or merged — the same organisation arrives with a different issuer
- Signing certificate replaced ahead of expiry — its own subject, and its own overlap rules
The identifier change is the expensive one
If a provider switches the subject format, the same human being arrives carrying a value your system has never seen. A naive implementation creates a second account, and the person signs in to an empty workspace and files a ticket saying their data is gone. It is not gone; it is attached to the identifier they used to have.
The defence is to decide, once and explicitly, which field is the join key and to store the alternatives alongside it rather than discarding them. Keep the issuer, the subject and the verified email together on the identity record. When a subject arrives that you do not recognise but an email matches an existing member of that organisation, you are in a position to make a considered decision — link, or refuse and escalate — instead of blindly creating a duplicate.
A changed subject format does not lose anybody's data. It just makes the same person unrecognisable to a system that only stored one identifier.
Find out before the ticket does
Where the provider publishes a metadata URL, poll it and compare. Most of these changes are visible in that document before a single user is affected, and a daily fetch turns a surprise outage into a scheduled conversation. Diff the fields that matter — endpoints, entity identifier, certificates — and treat a difference as an event that needs a human decision rather than something to apply silently.
Applying metadata automatically is defensible for certificates and rarely defensible for identifiers, because a change of entity identifier may mean the customer moved tenants or may mean somebody pointed the connection at the wrong directory. Log every applied change with a before and after value; the first question in any investigation is what the configuration looked like yesterday.
- Poll published metadata on a schedule and diff it rather than trusting notification emails
- Record configuration history per connection, with the previous value retained
- Alert on a first-seen issuer or subject format for an established connection
- Watch the account creation rate per organisation — a spike means an identifier moved
Make the error message do the work
The administrator who can fix this does not read your logs. They see whatever the browser shows, and if that is a generic failure page they will open a ticket, and the resolution time is now measured in the length of your support queue rather than the difficulty of the problem.
Name the field. An error page that says the assertion audience did not match the configured entity identifier, showing both values, is fixed by a competent identity administrator without your involvement. Keep it on a diagnostic screen behind the connection settings if you would rather not display internals to end users, but make sure the person who can act has somewhere to look that tells them exactly what to change.
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.