Which UI do you use?

Custom UI

Pre built UI

Share sessions across sub domains

Sharing sessions across multiple sub domains in SuperTokens can be configured by setting the sessionTokenFrontendDomain attribute of the Session recipe in your frontend code.

Example:

• Your app has two subdomains abc.example.com and xyz.example.com. We assume that the user logs in via example.com
• To enable sharing sessions across example.com, abc.example.com and xyz.example.com the sessionTokenFrontendDomain attribute must be set to .example.com.

ReactJS

You will have to make changes to the auth route config, as well as to the supertokens-web-js SDK config at the root of your application:

This change is in your auth route config.

supertokensUIInit("supertokensui", {
    appInfo: {
        // ...
        // this should be equal to the domain where the user will see the login UI
        apiDomain: "...",
        appName: "...",
        websiteDomain: "https://example.com"
    },
    recipeList: [
        supertokensUISession.init({
            sessionTokenFrontendDomain: ".example.com"
        })
    ]
});

This change goes in the supertokens-web-js SDK config at the root of your application:

import SuperTokens from "supertokens-web-js";
import Session from "supertokens-web-js/recipe/session";

SuperTokens.init({
    appInfo: {
        apiDomain: "...",
        appName: "...",
    },
    recipeList: [
        Session.init({
            sessionTokenFrontendDomain: ".example.com"
        }),
    ],
})

Angular

import SuperTokens from "supertokens-auth-react";
import Session from "supertokens-auth-react/recipe/session";

SuperTokens.init({
    appInfo: {
        // ...
        // this should be equal to the domain where the user will see the login UI
        apiDomain: "...",
        appName: "...",
        websiteDomain: "https://example.com"
    },
    recipeList: [
        Session.init({
            sessionTokenFrontendDomain: ".example.com"
        })
    ]
});

Vue

You will have to make changes to the auth route config, as well as to the supertokens-web-js SDK config at the root of your application:

This change is in your auth route config.

supertokensUIInit("supertokensui", {
    appInfo: {
        // ...
        // this should be equal to the domain where the user will see the login UI
        apiDomain: "...",
        appName: "...",
        websiteDomain: "https://example.com"
    },
    recipeList: [
        supertokensUISession.init({
            sessionTokenFrontendDomain: ".example.com"
        })
    ]
});

This change goes in the supertokens-web-js SDK config at the root of your application:

import SuperTokens from "supertokens-web-js";
import Session from "supertokens-web-js/recipe/session";

SuperTokens.init({
    appInfo: {
        apiDomain: "...",
        appName: "...",
    },
    recipeList: [
        Session.init({
            sessionTokenFrontendDomain: ".example.com"
        }),
    ],
})

caution

• Do not set sessionTokenFrontendDomain to a value that's in the public suffix list (Search for your value without the leading dot). Otherwise session management will not work.
• Do not set sessionTokenFrontendDomain to .localhost or an IP address based domain with a leading . since browsers will reject these cookies. For local development, you should configure your machine to use alias for localhost.

Multi Tenancy

In case you have a setup where each tenant belongs to one sub domain, and if a user has access to more than one tenant, the tenant ID as seen in the session will always be the one from which they logged into.

For example, if you a user has access to tenant t1.example.com and t2.example.com, and they logged in via t1.example.com, then the tenant ID in the session will always be t1 even if they navigate to t2.example.com, or make an API request from t2.example.com.

To solve this, you can add extra information about access token payload containing a list of all the tenants that the user has access to, and then read from that list instead of the tId claim.