We are currently working with Virto Commerce Platform version 3.306.0 and have a scenario that involves multiple storefronts/domains (for example: store1.com, store2.com, etc.) under the same Virto instance (or shared backend). We want to enable single sign-on (SSO) such that when a user logs into one domain, they remain authenticated (or can seamlessly access) across the other domain(s) without re-login. Our questions / requirements:
Does Virto Commerce Platform v 3.306.0 support cross-domain SSO out-of-the-box (i.e., built-in) across multiple storefront domains (not just within the same domain or sub-domain)
If cross-domain SSO is not supported out-of-the-box in this version, what is the recommended approach or best practice to implement it?
Are there any known constraints, limitations or security considerations when implementing cross‐domain SSO in Virto (v3.x) that we should be aware of?
My client requires that I do not update the platform version or integrate any SSO / OpenID solution. Therefore, I implemented a custom approach where a token is generated, stored in the database, and then validated through a login-with-token API endpoint after redirection. Once validated, I use the signInAsync function provided by Virto to authenticate the user.
This setup works correctly when navigating from x. com to y. com. However, after logging out from x. com and attempting to access x. com again through y. com, the HTTP request remains in a pending state in the browser, and the page only shows a white screen. The issue appears to occur specifically after the logout and subsequent redirect attempt. and if i disable the cache it is working properly
The described issue (pending request + blank screen after logout + redirect) is a symptom not of Virto’s signInAsync itself, but of browser cache, cookie, and token invalidation behavior across different domains. Any SSO between independent domains must be custom-implemented, looks, you’ve already done.
I recommend you check the option to use a wildcard cookie/domain, such as: .Domain = “.example.com”. Then you do not need custom token SSO at all — a single .example.com authentication cookie is enough. Virto 3.x already supports this scenario.
The safer approach is the one below:
Authorize user in Domain-A
Generate short-lived SSO token (1–3 min max)
Redirect to Domain-B with token?auth={token}
Domain-B calls backend API to validate token and:
Invalidates token (one-time use)
Signs user in using signInAsync
Use regular local cookies per domain after authentication.
PS: Although your current solution can be stabilized and secured, the customer should be informed that they are accepting structural risk. Virto strongly recommends upgrading to 3.865+ with standardized OpenID Connect, which solves: