One Identity Layer Across Every Product You Run

Build authentication once, in one place, and let every product inherit it. Do not let each product roll its own login, its own session handling, its own password reset. A single identity layer is the piece of a portfolio foundation with the highest cost of getting wrong and the highest payoff for getting right. Auth is security-critical, tedious, and identical across products. That combination is exactly what a shared foundation exists to absorb.

Why should identity be shared, not per-product?

Because auth is the same everywhere and it is unforgiving. Every product needs signup, login, sessions, password reset, and probably social login and multi-factor. None of that is a differentiator. No customer chose your product because its login form was special. Yet each implementation is a place to leak sessions, mishandle tokens, or store passwords wrong.

Building it per product means solving the same hard, dangerous problem twenty times, and being twenty times as likely to make a mistake in one of them. Build it once, to a high standard, and every product inherits the same audited, correct behavior. This is the clearest case for standardizing auth, billing, and deploy once. Identity is the first thing I put in a foundation, before anything product-specific, because it is pure inherited value with real security stakes.

A shared identity layer also means one place to fix a vulnerability. When a session-handling bug turns up, you patch the identity layer and every product is fixed at once. With per-product auth, you are patching the same bug twenty times and hoping you found all twenty.

Shared identity does not mean one login for customers

Be precise about what "shared" means. A shared identity layer is shared code and shared infrastructure. It is not necessarily a shared user account across your products from the customer's point of view.

Two different models, and you should pick on purpose:

• Shared code, separate tenants. Every product uses the same identity library and service, but each product's users are its own. A customer of product A has no account in product B. This is the common case and the right default for a portfolio of unrelated products.
• Shared identity, single sign-on. One account works across multiple products. This makes sense only when products are meant to feel like a suite, and it adds real complexity around permissions and account linking.

Most portfolios want the first model: reuse the machinery, keep the user bases separate. The mistake is assuming shared code forces a shared user directory. It does not. You can run one identity codebase serving twenty completely isolated tenant boundaries, which is also cleaner for data separation and for any customer who asks where their data lives.

The security case for one identity layer

Concentrating auth in one place sounds like concentrating risk, and people worry it creates a single point of failure. The opposite is true for security. Spreading auth across twenty products spreads your attack surface across twenty implementations, each with its own bugs, its own outdated dependencies, its own subtle mistakes. You cannot audit twenty things as well as you can audit one.

One identity layer means one thing to harden, one thing to keep patched, one thing to review. You put your security attention where it concentrates the most risk instead of thinning it across a portfolio. The availability concern is real and you handle it the way you handle any shared dependency's blast radius: redundancy, monitoring, and a version products pin so an identity update cannot break every product at once.

Transactional email is part of this too. Verification, password reset, and magic links all flow through the identity layer, so I run them through one owned sending path rather than per-product setups. Keeping transactional email as infrastructure means every product's auth emails deliver, and I fix deliverability once for all of them.

Build it once and stop thinking about it

The goal of a shared identity layer is to make auth a solved problem you never revisit per product. New product needs login? It inherits the identity layer and login exists on day one, correct and secure, with nothing to build. That is the foundation doing its job: converting a hard, repeated, dangerous task into inherited default behavior.

I keep this frictionless by scaffolding every new product already wired to the identity layer, so Bootspring stands up a product with working auth before I write a line of product logic. Auth stops being a project and becomes a checkbox that is already ticked. That is the whole point of a foundation: the hard parts are already done, and every new product starts ahead.