Single sign-on across a product suite, explained

Single sign-on across a product suite means a person logs in once and can move between every product you offer without making a new account each time, and signs out of all of them together. It is the Google-style experience: one identity, many products. For a company shipping more than one product, it is the difference between feeling like one company and feeling like a pile of unrelated tools.

We run several products at BotBrained: a CRM, a verification service, and a handful of smaller tools. Someone who pays for one of them should be able to try another without filling in a signup form again. Here is how we think about building that, and why it is very achievable on modern cloud infrastructure without bolting on a heavyweight identity provider.

One identity, not one account per product

The tempting first move is to stand each product up in complete isolation, with its own separate users. It feels tidy, and it makes single sign-on almost impossible: a login for one product means nothing to the next, so you end up syncing user records between systems and reconciling two sources of truth every time someone changes their email.

We go the other way. There is one place a person exists, one identity, created once. A user signs up a single time and that account is who they are across everything we run. Whether they can actually use a given product is a separate question from who they are, and that separation is the key idea.

Access is a grant, not a side effect of having an account

Existing as a user does not mean you can walk into every product. Access to each one is an explicit permission that is granted when someone subscribes and revoked when they stop, without deleting their account. They keep their login; they simply lose entry to that product until they come back. This keeps billing, trials, and churn clean: turning a product on or off for a customer is a single permission change, not an account migration.

Security belongs in the data layer

The principle we hold to most strictly is where access gets enforced. A check written only in front-end code is a convenience for the interface; it decides which buttons to show, but it is never the security boundary. The real gate has to sit with the data itself, so that even a correctly authenticated request aimed at the wrong product comes back empty. If access control is not enforced where the data lives, we assume it is not enforced at all.

Application checks decide what the interface shows. The data layer decides what a user can actually touch. Only the second one is security.

Token-based, so it works everywhere

Our products are built to be native-app-ready from day one, which rules out anything that assumes a web browser is the only client. So authentication travels as a token with each request rather than as a browser cookie. The same login then works identically from a website, a future mobile app, or a server-to-server integration, with one consistent contract instead of a special case for each. That single decision is what keeps the door open to mobile and partner integrations later, without re-architecting auth.

What it buys you

Once the identity layer is in place, adding the next product is mostly mechanical: the login, the accounts, and the permission model already exist, so a new product plugs into them rather than reinventing them. New product, zero new login. The cost is discipline. A shared identity is critical infrastructure, so it gets treated and monitored as such, and access rules get tested properly, because a permission that is quietly too generous is exactly the kind of issue that does not announce itself.

None of this is exotic. It is modern cloud infrastructure used the way it is meant to be used, with access decisions pushed down to where the data lives. We build and run this across our own product suite at BotBrained. If you are planning more than one product, it is worth getting the identity layer right before you are retrofitting it across five.