One identity layer, three products, and why we did it the hard way

The default path when a company builds a second product is to copy the first product's authentication and change the branding. It works, it is fast, and it is how most small software companies end up with three subtly different session models and no single answer to the question of who a user is.

We went the other way and built identity as its own service before the second product needed it.

What sits where

The identity service owns who someone is and which applications they may reach. Each product owns what that person may do once inside. Those are genuinely different questions and conflating them is what makes permission systems impossible to reason about later.

• Identity service: accounts, credentials, sessions, application access
• Product: roles, permissions, and what a given action requires
• Neither: guessing what the other one decided

The part that pays off

A product that does not verify passwords also does not store them, does not implement password reset, does not handle account recovery, and does not carry the breach surface that comes with all three. It receives a short-lived token, verifies it against a public key, and gets on with its own job.

That reduction compounds. The third product cost meaningfully less to start than the second, which is the outcome you are hoping for when you take on this kind of work early.

What it cost

Two systems to run instead of one, a network hop in the login path, and the discipline to keep the boundary clean when it would be quicker to reach across it. The failure mode is a product reaching into identity for something that is really its own concern, and the fix is to notice it early.

It was the right trade. It is not always the right trade, and for a company with one product that will stay one product, it clearly is not.