One identity across systems does not mean one permission model

The browser returns from Microsoft, Google, MitID, or another provider. The signature is valid. A name and identifier are present. The user sees the application. It is tempting to call the integration complete because this is the moment everybody can observe.

What the application actually learned is narrower: one provider made one assertion about one session under one assurance context. It has not learned whether this is the same person who used another provider last month, which organisation they currently belong to, whether an upstream suspension has arrived, or whether they may approve a payment inside this product.

Identity architecture fails when proof of personhood is allowed to become proof of authority by convenience.

A provider-neutral hub gives products a stable internal subject and a consistent way to receive identity context. Its provider boundary is designed to support MitID, workforce Microsoft accounts, and consumer Google accounts, resolving them to the same internal person while preserving the assurance context, contractual constraints, and recovery properties that make those assertions meaningfully distinct.

Preserve those properties in the identity envelope. The product may not care during an ordinary read, but a high-impact action may require recent authentication, a particular provider, or a stronger assurance level. Provider neutrality means the product does not implement every protocol. It does not mean every assertion becomes equivalent.

Consider how this operates across independent products in the ecosystem: an operator in Garage CRM holds authority over vehicle reservations, rental contracts, and asset releases. That same person authenticated in Grand Total holds authority over member subscriptions, payment reconciliations, and financial reporting. The hub normalises who they are; the products retain complete, independent ownership of what they are allowed to decide.

Provider federation works cleanly while every person keeps one account and every identifier remains stable. Recovery breaks that assumption. A person loses a device, changes employer, receives a new provider account, or returns after an account was deactivated. The convenient response is to link on email address. That is also how two people can be merged when an address is recycled, renamed, or entered incorrectly.

Linking therefore needs evidence separate from sign-in. A provider assertion can prove control of the new account; it does not prove that the new account should inherit the history and authority of an existing internal subject. Depending on consequence, a safe link may require an authenticated session on both accounts, an organisation administrator, an out-of-band recovery process, or manual review. The hub should record who approved the link, which evidence was present, and which previous mappings were replaced.

Recovery also needs a product response. If an internal subject is suspended because its mapping is disputed, connected products must know whether to end sessions immediately, block only high-impact actions, or permit read-only access while an investigation runs. That decision cannot be improvised during an incident. It belongs in the identity contract and should be exercised before the first real account dispute.

An unavailable provider is obvious. The subtler failures are a stale role that still works, two provider accounts linked to the wrong person, a deactivation event that never arrived, or a tenant switch that reuses authority from the previous organisation. These cases return valid tokens and ordinary HTTP responses. Availability monitoring will not find them.

A single application with one stable provider, no cross-system identity, and a small user lifecycle may be clearer when it integrates directly. A hub added before there is a second consumer can create mapping, availability, and operational work without removing any real duplication.

The threshold is not a number of login buttons. It is the first repeated identity decision: a second product, a second provider, a shared person represented differently, or an assurance rule several systems would otherwise interpret independently. That is where a stable boundary begins to pay for itself.