Redefining the Login Layer for Commerce

Bolt Team

Author

Maju Kuruvilla

CEO

Get updates in your inbox:

Redefining the Login Layer for Commerce

Redefining the Login Layer for Commerce
Building Bolt SSO Commerce™

Why We Built SSO Commerce

One of the key benefits of Bolt’s checkout experience is that creating a one-click account is effortless. This is incredibly useful for shoppers, because they can use their saved shipping and payment information for a one-click checkout on any website that uses Bolt. However, these one-click accounts are separate from the individual store accounts that shoppers use to view past orders, access wish lists, and more. With the introduction of Single Sign-On (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 need to ensure that all login points on a retailer’s site (i.e., the “My Account” or “Add to Wish List” buttons that direct shoppers to login walls) are powered by Bolt. When a shopper attempts to login, we use OpenID Connect to let shoppers securely share their information (i.e., user ID) with the retailer they’re visiting. Bolt will then use this information to create/login to an account in the retailer’s system.

During the development phase, we had to decide whether to use OAuth/OIDC, SAML, or a custom protocol. Ultimately, 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.

OAuth Implementation

One of the first pieces we tackled was implementing the OAuth Authorization Server and Resource Server protocols in our backend. To implement this functionality, we had a few different options:

  • 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.
  • 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.
  • 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.
  • 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.

    SSO Commerce Component

    We also built a login/registration component as a drop-in replacement for retailers’ original login flow, allowing them to easily prompt shoppers from any part of their website. This component encapsulates all of the logic to perform Bolt’s passwordless authentication and interact with our OAuth backend. Here’s a quick rundown of what happens during a successful login:

    • The component checks for an existing Bolt session, and doesn’t find one
    • The shopper is prompted to enter their email
    • The component detects an existing Bolt account, and prompts the shopper to enter a one-time password (OTP)

    The component establishes a Bolt session and kicks off the OAuth authorization flowOne of the key breakthroughs of SSO Commerce was the realization that Bolt could securely log shoppers into an existing store account once they verified their email. In addition to the basic flow described above, the SSO Commerce component will detect the status of each shopper’s store account and prompt for additional verification when necessary.

    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:

    • 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.
    • 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 open our login/registration component.

    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.

    REQUEST YOUR COPY


    Submit the form and we’ll email your copy.