Single Sign-On (SSO) in an Online Store: What It Is and When You Need It

Single Sign-On (SSO) is one login for several systems at once: the customer confirms their identity once and gets into the store, the mobile app or a platform for business buyers without another form. The convenience is obvious right away, which is why SSO is easy to sell and easy to buy too early. It starts to make sense with a second channel, and the full bill only arrives on the day you want to change your login provider. We show this on two Magento stores: at Bolero, the choice was made before the first line of code, and in the other one, changing providers broke the login in the mobile app.

What is Single Sign-On (SSO) in an online store

Single Sign-On (SSO) is one login that gives the customer access to several of your systems at once: the store, the mobile app, the B2B platform. One account, one password, and then the customer gets in wherever you allow them to, without another form. As an answer to “what is single sign-on”, that is enough. For a store, it is only the start of the conversation.

The mechanics are simpler than the acronym suggests. Login stops living in the store and moves to a separate system, the identity provider. The customer enters their details there once and gets a token in return: a signed proof that they are who they say they are. Every connected channel checks that token and lets the customer in without asking for a password. Under the hood sit standards such as SAML or OIDC, and for now it is enough to know they exist.

A customer has been buying from you for two years and has an account, an order history and a saved delivery address. They install your app, and the first thing they see is a sign-up screen. To them, it is the same company and the same account. To your systems, these are two separate user databases that know nothing about each other, and two places where passwords have to be changed, access reset and support questions answered.

Most articles about SSO end here with a list of benefits: convenience, fewer passwords, centralized control. None of them tells you whether to do it, or how. Our projects point to something else: the most expensive decisions are made long before implementation, and the first one is where your customers’ accounts live.

Is Google login SSO?

Not in the sense a store means when it plans SSO. The “Sign in with Google” button is technically a close relative: there is an external identity provider, there is a token, there is one authentication instead of yet another password in your database.

But signing in with Google or Facebook, known as social login, solves one specific problem: friction at sign-up. The customer does not invent a password or confirm an email, and is in after two clicks. The price is that the choice of identity stays with the customer. They decide which account to bring, and that account is controlled by a third party.

SSO answers a different question. How do you make the channels you own recognize the same account, with access to it held in one place on your side? The store, the app, a panel for sales reps. Social login lowers the barrier for the customer. SSO gives you one point where you grant or revoke access, in all channels at once.

The two do not compete and often sit side by side: an identity provider on your side, with Google sign-in as one of the available methods. The confusion only starts to cost money when it replaces a decision. “The customer won’t need to remember a password because they’ll click Facebook” is an argument for social login. If that argument dominates the implementation discussion, you end up running a whole project to do what one button on the sign-up form already does. Ask about channels separately.

When an online store needs SSO

A store needs SSO when it has a second channel (an app, a second store, a platform for business buyers) and the customer is supposed to have one account across them. The Bolero mobile app did not get its own login form. It was built in React Native as a separate sales channel and talks to only two systems: a read layer that serves it the catalog, and Keycloak, which recognizes the customer. Magento remained the source of truth, and orders and payments go back to it on a schedule. We describe how such a read layer works in our article on ecommerce integrations. Login moved one layer down, to a separate account layer, so there is no reason to build it into the app.

The missing login form was not a decision about the app. It followed from an earlier decision about where the customer’s account lives.

The same problem shows up in other setups. A second store on the same customer base, a separate domain for another brand, where shoppers should have one account across both. A platform for business buyers, where several people from the purchasing department work under one company account and each has their own access. Company accounts come with enough complications of their own that we treat them separately, in B2B platforms.

A single-channel store gets nothing from SSO that it does not already have with ordinary login: there is still one user database, one form and one place where the customer resets their password. We have no conversion data after an SSO rollout, and no basis for linking SSO in an online store with abandoned carts.

Where accounts live

Where should your customers’ accounts live? The question sounds technical, so it usually comes up only after a tool has been chosen, when someone has already answered it for you.

In practice there are four options, and they form a spectrum:

• In the store’s database. Every platform works this way by default, and as long as you have one channel, there is no reason to change it.

• In a separate identity layer you keep in-house, on your own server and in your own code.

• With a provider that sells identity as a service. You maintain nothing, but the bill grows with the number of accounts.

• On the ecommerce platform, which holds the accounts while you use them on its terms.

Everything else, including how SSO is implemented in your online store, follows from that one answer.

The last option has a high-profile variant: Shoper ONE gives shoppers one account for buying in more than twenty thousand stores on that platform, and according to Shoper, in the first thirty days the number of logins passed 600,000. That is platform SSO, not SSO for your own channels: one customer account works across many stores on the same platform, and your store is one of them.

Bolero chose the second option: a separate account layer based on Keycloak and a module that connects it to Magento. What came before the choice is more interesting than the choice itself. Before the first line of code, we compared two variants using sequence diagrams: a custom SSO built on django-allauth, or Keycloak as an off-the-shelf identity provider. A POC before a migration at another client and integration workshops at yet another started the same way. We chose Keycloak in both projects described here.

A single customer profile comes from exactly this decision. Accounts live in one place, so customer data has no way to drift apart into two databases.

Ask one more question before you choose: what happens to the accounts and passwords you already have? Each of the four options handles it differently, and your implementation partner should know how before the project starts.

Off-the-shelf module, service or custom build

There are three routes. An off-the-shelf module, a provider as a service, a custom build. Guides put them side by side like rows in a table, with a price column and an implementation time column, and in that kind of comparison the off-the-shelf SSO module always looks the most sensible. The difference between them shows on the day you want to change something.

A store with a mobile app that we worked with ran login in both the store and the app on the paid miniOrange Enterprise module, connected to Auth0 as the identity provider. So it paid twice: for the module and for the provider. Getting rid of the license and the provider fees was one of the reasons we are rebuilding that login. We have not yet calculated what it will save.

Then switching off the old module broke the mobile app’s login endpoint. The app authenticated customers at a specific address that belonged to the module, and the address disappeared together with the module. We recreated it with an identical contract, and our own Keycloak-based module, with full token verification, is set to take over login. We split the rest of the project into stages, each with its own quote, instead of switching everything over in one move.

For anyone still choosing a login solution, this leaves one rule. Treat the app’s login contract like a public API: you may replace the identity provider behind it, but you may not touch the address or the shape of the response the app expects. On the day of the change, everything the module exposes to the outside world turns out to be your commitment.

You see the price of an off-the-shelf module right away, in the price list. What it costs to leave, you only find out when you try to leave.

Is SSO secure?

SSO makes a store more secure, but only once someone takes care of the implementation details. The password no longer sits in several databases and lives with a single identity provider. Fewer places it can leak from, and one place where you can enforce rules: password length, lockout after failed attempts, forced password change. With two separate logins, you set each of these twice, or not at all.

One account now opens every channel, so a hijacked account opens them just as well. That is why two-factor authentication, short sessions and alerts about logins from a new device belong to the scope of the implementation. If your implementation partner prices them separately, as something to consider in a second stage, ask what protects that one account in the first stage.

Full token verification on the store side looks like an implementation detail, yet that is exactly where the “but only once” is decided. A store that accepts a token because it looks like a token, without checking the signature, the expiry and who it was issued to, lets in anyone who knows how to craft such a token. Our own Keycloak-based module, which is set to take over login in that mobile app, has this verification built in. No provider or implementation partner can give you a security guarantee, because nobody controls everything at once: customers’ devices, customers’ passwords and even their own code. What you can check is whether the implementation has those three safeguards and whether the token is verified on the store side. Ask your implementation partner about it before you sign the contract.

Summary

You will rebuild the store, replace the front end, and one day change platforms. The account database stays. Customer accounts pass through successive versions of the store and move from system to system, collecting purchase history, addresses and consents that you cannot rebuild from anything else. So login goes into the specification among ordinary features, yet it behaves like a commitment: the decision about who stores your customers’ identity stays with the company longer than most of the technologies you pick at the time. Where do your customers’ accounts live today, and who holds the key to them?

If you want to see what this means for your store and your planned channels, book a free consultation. We will go through these decisions one by one and tell you what they mean for the scope of the implementation.