Merchant Login

Thanks for signing up!

Bolt Blog

Redefining the Login Layer for Commerce
Building Bolt SSO Commerce™

Why We Built SSO Commerce

One of the key value-adds of Bolt’s checkout experience is that creating a one-click account is effortless. This is incredibly useful for shoppers, because when they return to a Bolt checkout anywhere across the web, they can use their saved shipping and payment information for a one-click checkout experience. However, these one-click accounts are separate from the individual store accounts that shoppers use to view past orders, access their wishlist, and more. With the introduction of SSO Commerce, we unify these two experiences by providing Bolt’s best-in-class login and store account registration as a service. Not only does this make it easier and more secure for shoppers to access their store accounts using Bolt’s passwordless login, it also allows us to leverage our seamless in-checkout registration experience to create more store accounts for our retailers without impacting conversion. Read on to learn how we built SSO Commerce which is redefining how retailers can engage with their customers.

Behind the Scenes: OAuth 2.0 and OpenID Connect

Under the hood, SSO Commerce leverages the OAuth 2.0 and OpenID Connect (OIDC) standards for providing authentication services to third-parties. These are the same technologies powering social login buttons like “Login With Google/Facebook/Apple.” However, SSO Commerce differs from these other products, because it is specifically built for commerce.

In order for SSO Commerce to provide shoppers a single, unified account experience, we needed to ensure that all login points on a retailer’s site (i.e., the “My Account” or “Add to Wishlist” buttons that direct shoppers to login walls) could be authenticated and powered by Bolt. This is where we used OpenID Connect to allow retailers’ platforms to request information (i.e., user ID) about authenticated Bolt users. In turn, this was also used by the platform to create/login users in their own system.

When it came to deciding whether to use OAuth/OIDC, SAML, or a custom protocol, OAuth/OIDC made the most sense, because it’s currently the most popular method for authentication via a third-party service. SAML is more popular for enterprise, business-to-business (B2B) websites and building our own custom protocol meant extra work to support additional functionality in the future. With OAuth/OIDC, a lot of what we might want to build has already been thought out and incorporated into the protocol in a secure way.

Hail Endpoints

We also needed to implement the OAuth Authorization and Resource server protocols in our backend (Hail), which involved several new endpoints. To implement these endpoints, we had a few different options:

  1. Using a self-hosted OAuth server which connects to your own login and user management services. One issue with the self-hosted solutions we evaluated is that they also perform the session management for your system. This was a non-starter for us, since we needed to control this functionality.
  2. Using a hosted service provider like Okta which takes care of everything. We hit the same roadblock here since these services take over handling the authentication sessions for your system.
  3. Writing everything ourselves. This approach would require quite a bit of work and also increased the surface area for introducing potential security bugs. Since this is such a critical and security-sensitive system, we decided it was preferable to rely on a well-maintained and widely used implementation of this core functionality.
  4. And lastly, the decision we ultimately chose: using an OAuth library to help build our own OAuth endpoint. This gave us more flexibility, and allowed us to rely on pre-built functions for OAuth/OIDC under the hood. With this approach, we would need to provide our own implementations for each endpoint, calling into the correct library functions as necessary. But at the same time, we could rest assured that these functions had been thoroughly vetted and could stand the test of time.

Frontend Changes

In addition to the work required in the backend, there were also several frontend changes for SSO Commerce, which is a customer-facing login layer on our retailers’ sites. We also needed to ask for a user’s consent in two key places in order to create store accounts on behalf of our retailers:

  1. Account logins (previously hosted by the retailer)
  2. Checkout (already powered by Bolt)

If a shopper already has a store account with that retailer, we simply log them in. Logging into the store account in all instances involves the following steps:

  1. The login flow checks the session and either confirms an active session or prompts login.
  2. Bolt authentication occurs on the login page:
    1. For customers that don’t have an existing Bolt account, they can create one.
    2. If the phone number matches an existing account, they enter a code to login.
  3. On successful login, the user will be redirected back to the /oauth/authorization endpoint.

Plugin Changes

One of the biggest areas of focus for Bolt is building products that work across multiple shopping platforms. From BigCommerce to Magento to Salesforce Commerce Cloud (SFCC), our retailers use a diverse set of platforms to power their sites and it’s important for us to create products that are built with this in mind. Below are some examples of specific plugin changes required to build SSO Commerce:

  1. Magento and SFCC:
    • We built plugins for both of these platforms to implement the client-side logic of the OAuth/OIDC protocols. This included adding the necessary endpoints to receive the OAuth authorization code and exchange it for an ID token, as well as the functionality to assign and lookup the store account users associated with the Bolt-provided ID.
  2. BigCommerce:
    • BigCommerce actually has its own special protocol for logging in via an external identity provider. We built an endpoint that creates a signed JWT token identifying a BigCommerce account. We then redirected to a BigCommerce-defined URL with the token in the query parameters.

In order to build out a full OAuth/OIDC based authentication system, a substantial amount of engineering work was required to implement both sides of the protocol. That’s why we’ve taken so much care to ensure that integrating SSO Commerce is as simple as possible for our retailers. Rather than asking them to build the client-side functionality on their own, these plugins do the vast majority of the heavy lifting. From a retailer’s perspective, integrating with SSO Commerce is as simple as turning on the feature and adding a button to their website to initiate the login/registration flow.

Closing Thoughts

We are thrilled to build a feature that prioritizes retailers’ growth while simultaneously providing a more secure account experience for shoppers. With SSO Commerce, retailers can easily acquire more customer accounts and replace their lengthy registration processes with a simple checkbox. As for shoppers, they login as they normally would on a retailer’s site, except without the burden of remembering countless username and password combinations. SSO Commerce is redefining the login layer for commerce and starting the shift towards personalized, rewarding shopping experiences becoming the default for independent retailers. We couldn’t be more proud to announce its launch to the market today.

To learn how to get started with SSO Commerce, learn more here.

Want to watch Bolt in action?

Get a demo