Session Bridge Authorization
The SLAS Session Bridge pattern allows for a quick and secure transition from the Commerce Cloud session (stored in the B2C Commerce Session ID cookie DWSID or DWSGST token) to a SLAS Shopper Token either as guest or named user. This enables ALL SCAPI API endpoints to be available for use in their hybrid or composable app.
There are times when SLAS is incorporated into a hybrid environment where part of the application is a standalone (Single Page App SPA) or mobile app and part is using an SFRA storefront. As part of this application pattern there are times when the shopper authenticates (either as a guest or a named shopper) with B2C Commerce directly gaining a session stored in the DWSID cookie.
The plugin_slas cartridge includes the SLAS Session Bridge flows, effectively enabling B2C Commerce signed guest session (DWSGST) and B2C Commerce registered user session (DWSID) to get a SLAS Shopper JWT for use with SCAPI and OCAPI.
The following diagrams show the typical API requests and responses used in the SESB flow:
SESB with signed guest session is a single call to SLAS to obtain a SLAS Shopper JWT. This is fast because the signed guest token signature is validated by SLAS with no calls into B2C Commerce for validation.
To get a DWSGST you must have a B2C Commerce cartridge with a controller that calls the session.generateGuestSessionSignature() script API and then return the result. It’s outside of this document on how to build a cartridge for B2C Commerce, but the following sample is very simple code showing what the controller would do.
After you have a DWSGST token, request a SESB token from SLAS using getSessionBridgeAccessToken. In the Call 1 command, replace eyJraWQiOiIxNjkxMTM1NTIWxnIjoiRVMyNTYifQ.eyJ0ZW5hbnRJZCI6I... with the actual DWSGST.
SESB with registered user session is two calls to SLAS to obtain a SLAS Shopper JWT. This is slower because of the validation in SLAS and B2C Commerce that happens.
Deprecation Notice: After January 31, 2024 merchants will no longer be able to use the DWSID parameter and loginId=guest on the /session-bridge/token. You must use the SESB Signed Guest token flow to get a SESB guest token. Beyond this timeline, accessing this API returns a 404 error and prevents your guest shoppers access to your storefront. For more information, see Shopper Login and API Access Service(SLAS) Session Bridge DWSID GUEST Deprecation
The request redirects the address provided in the redirect_uri parameter of the previous request. When redirecting, the authorization code is included as a query parameter.
Now that you have an authorization code, you can request a SESB token from SLAS using getSessionBridgeAccessToken. In the Call 2 command, replace jpsM6DNwzFtrUIZJDwyRihkRX1g with the actual authorization code.
There are several ways a user can log in with SLAS. All registered user login flows are supported by SESB.
- SESB to third-party IDP (/authorize) Private Client or Public Client
- SESB to B2C Commerce user (/login) Private Client or Public Client
- SESB to Trusted System on Behalf (TSOB)
- SESB to Trusted Agent on Behalf (TAOB)
- SESB to Password-less User Login (/passwordless/login)
In this scenario as the shopper starts with a signed guest token then creates and places items in a basket. At some point the shopper logs in using any of the SLAS login flows with the guest USID and the guest session is transitioned to a registered user session.
