Designing authentication across multiple products

Once a company has more than one product, a natural question is whether users should have one account across all of them or a separate account per product. There's no universally correct answer, but the trade-offs are consistent enough to reason about in advance, before user data gets tangled across systems.

Shared account, separate products

A shared identity provider (email, phone, or a third-party sign-in like Google) that issues tokens multiple products can accept is the most common pattern for a small company. It means a user signs in once and doesn't need to remember separate credentials per product, and the company maintains one authentication system instead of several. The cost is that the identity provider becomes a single point of failure and a single high-value target: if it's compromised, every product it protects is affected.

What belongs in the identity layer versus the product layer

Identity layer: who the user is, how they proved it (password, OTP, OAuth), and session/token issuance.
Product layer: what that authenticated user is allowed to do inside a specific product — permissions, roles, and product-specific data.

Keeping these separated means a product can define its own authorization rules without needing to modify the shared authentication system, and the authentication system doesn't need to know anything about product-specific business logic.

Practical requirements for a shared system

Multiple sign-in methods where reasonable. Supporting email, phone, and a federated option like Google sign-in reduces account-recovery friction, but each method needs its own verification step (email confirmation, SMS OTP, OAuth token validation) rather than being trusted blindly.
Session handling appropriate to sensitivity. Pages that show or change account data should be served with cache headers that prevent shared caches from storing them (for example, Cache-Control: private, no-store), and should not be indexed by search engines.
Least privilege for administrative roles. Any elevated access (employee or administrator roles) should be explicitly invitation-based or allow-listed rather than self-service, and the list of who holds elevated access should be small and known.
Clear separation of concerns with the identity provider. If authentication is delegated to a third-party provider (for example, a hosted auth/database service), the product only needs to trust that provider's issued session, not re-implement password storage itself.

A common mistake worth naming

A frequent error in small systems is conflating "signed in" with "authorized." Just because a request carries a valid session does not mean the signed-in user should be allowed to perform the specific action requested — that check belongs explicitly in the product layer and should never be assumed from the mere presence of a valid session token.