A company with multiple products can accidentally create multiple versions of the same person. Each application knows a slightly different email, role, organization, consent status and account lifecycle. These differences appear insignificant until the person changes companies, loses access to one product or exercises a data right across the ecosystem. The source of risk is not necessarily weak cryptography. It is an unclear answer to a deceptively simple question: who is this actor, and which organization is the actor representing right now?
Central identity is valuable when it provides dependable answers without consuming every product's domain logic. Authentication proves control over credentials. Organization membership establishes a relationship. Licensing determines entitlement for a particular product. Authorization decides which action is permitted in a particular context. These are connected but different questions. Turning all of them into one global user role creates shortcuts that become security and product-design debt.
A practical architecture makes context explicit: principal, tenant, product, scope, session and evidence of consent. Tokens should be short-lived and limited in meaning. Cross-product navigation can be seamless while sensitive entitlements remain verified at the point of action. A person's right to access billing information in one organization should not follow the person into a different organization merely because the browser session is shared.
The difficult trade-off is central availability. When a common identity service is unavailable, what should happen to an already-authorized reservation, a payment callback or a read-only report? Different actions require different answers. Resilience means deciding the failure policy in advance, including which cached claims can be trusted, for how long and under what revocation conditions. Identity is not only a login feature. It is a contract between products about the limits of trust.