The Challenge

Boardriders, a leading action sports and lifestyle company for boardriders around the world represents a casual lifestyle for young-minded people are passionate about outdoor action sports. In July last year, the Business Operations Manager of Boardriders posted this query on the Salesforce B2C Commerce Cloud discussion forum at their developer centre in July last year:

Hello, we are looking to extend the shopper session for our sites. Right now, the shopper session, if logged in, is only active for 30 mins or so. Is there a way for us to allow our shoppers to be always logged in until they explicitly logout?”

He did get a response with a temporary fix from a member of the Salesforce developer community. But little did they expect that in less than a year, Salesforce Commerce Cloud would permanently solve the issue.

Headless commerce has always been about enabling developers to create robust e-commerce platforms that give visitors a richer user experience. This, in turn, drives customers through the sales funnel quickly and seamlessly. However, session timings since the last interaction was limited to just 30 minutes. Maintaining a user session for longer in a secured environment has been a challenge for developers at Boardriders, as well as several merchants and e-commerce users across the globe.

The Solution

Enter Shopper Login Access and API Access Service or SLAS, a quick and easy way to extend the user session period as well as increase accessibility by letting you offer multiple ways to your customer to log in. SLAS is a set of APIs that allows secure access to Commerce Cloud shopper APIs for headless applications.

The introduction of OAuth 2.0-based login APIs was critical to the introduction of SLAS. This is what allows a shopper to stay logged in for up to 90 days, as opposed to 30 minutes. Sounds interesting? Here is how it works.

This high scale authentication and authorization solution provides secure access to the Commerce platform’s Shopper APIs. It enables merchants to develop functionality that lets shoppers log in via federation to an Identity Provider (IDP) of their choice. This means your customer can log in to your website using the same credentials they use for logging into their Facebook or Google accounts.

Using SLAS, you can enable single sign-on and allow your customers to use a single set of log-ins across multiple environments (for instance, Commerce Cloud vs. a Community Portal). With SLAS, you can also use third-party identity services that support OpenID like Facebook or Google.

Letting a session go on for 90 days is user-friendly indeed. But from the security angle, it makes more sense to allow 90 days in a mobile application environment rather than a web browser, given public or shared computer may lead to user details staying exposed for longer than desired. It’s a call you have to take at the end of the day in consultation with your development, security and legal teams.

But why do you need SLAs anyway?

To be honest, you could already do the above with SFRA and SiteGenesis. The above login types are already possible within the current setup. But they can’t be used for other applications. If you want these to work for other applications such as endless aisle, kiosk, or mobile app, you will need to build a custom implementation for each.

On the other hand, SLAS is a headless API that can be used by all of your channels, and it does not matter if they are on Commerce Cloud or not. Besides the ability to extend the session time up to 90 days, you can also take advantage of the Single Sign-On feature. If you are already live on Salesforce B2C Commerce Cloud using SFRA or SiteGenesis, you can transfer sessions between channels more easily.

Benefits of using SLAS in SFCC

How to use SLAS if you have monolithic setup

If you are using SFRA, you have the advantage of quickly incorporating new features to enhance the digital shopping journey of your customers. So if you want to get on the SLAS bandwagon, you need to use the new all-in-one feature cartridge (plugin_cartridge_merge) that makes it easy to install and use several optional SFRA features in your current setup without the help of a developer. It also makes it easy to selectively disable optional features. You get to a true headless commerce player when you use the cartridge to bring all of the advantages of SLAS to SFRA, a monolithic setup.

However, keep in mind that there are a few risks:

  • Using SLAS can impact your site’s performance a bit since the cartridge adds three to four remote API calls to the flow. But there’s nothing to worry about as these Salesforce services abide by the same performance and uptime rules as the other B2C Commerce services.
  • 4 remote APIs(2 SCAPI and 2 OCAPI calls) are used to get the login and registration through SLAS to work. This leaves you with 4 API calls remaining that you can do during the log-in procedure. According to an update, 5 API calls are needed during registration in some cases, which makes up for a large part of your “budget”

You can continue to use SiteGenesis, however, it won’t be plug-and-play anymore, as it was the case with SFRA. But the code is simple enough and can be used as a cheat sheet to implement the desired version for SiteGenesis.

How are SLAs useful?

Commerce Cloud Storefront Reference Architecture (SFRA) – What are the things you need to consider while you make a move?

Conclusion

SLAS can help extend user sessions in a secured environment. This headless API can work across channels. Besides extending the session time up to 90 days, users can also take advantage of the Single Sign-On feature. For those on a monolithic set-up, this could mean working in an all-in-one feature cartridge that unlocks many optional SFRA features without the help of a developer.

References

https://developer.salesforce.com/docs/commerce/commerce-api/guide/slas.html

https://developer.salesforce.com/blogs/2022/01/shopper-login-api-level-up-security-and-trust-in-all-headless-commerce-applications

https://www.rhino-inquisitor.com/slas-in-sfra-or-sitegenesis/