SuperTokens is an open source authentication solution offering features like: Different types of login: Email / password, Passwordless (OTP or Magic link based).

SuperTokens.com

**SAML SSO across different domains**
So our supertokens apiDomain is  `api.xxx.com` and the front end websiteDomain is `identity.xxx.com`,  but because we have a use case where we need to support custom domains, and the application will be running on `yyy.com`. I am using `jackson`  using a custom provider to do SAML SSO. What would be the best way to handle this? I know we can set the access token in a custom header and store it in the local storage, but I am not a fan of that approach.

Hi <@1027828425706192997>,

So one way to solve this would be to add a CNAME to your DNS settings that makes `api.yyy.com` to point to `api.xxx.com`. But if you cant do this, the problem would be that the normal set up wont work with Safari because it blocks third party cookies

In which case the header based approach with local storage would be the way to go

Sorry, but I'm not sure I understand. The cookie is set with the domain `.xxx.com`  right? So how will pointing `api.yyy.com` to `api.xxx.com` help? How is `api.yyy.com` used?

ah well yyea.. you are right <@1027828425706192997> . The right way to solve this issue would be to create a separate session on yyy.com between yyy.com and api.yyy.com (which points to api.xxx.com)

and you can create its own session by redirecting the user to yyy.com with a JWT in the redirect URL. yyy.com sends that JWT to the backend (api.yyy.com which just points to api.xxx.com) and that verifies the JWT and calls the Session.createNewSession function in that API.

This will create a session between yyy.com and api.yyy.com.

This will happen even if the apiDomain on the backend is set to api.xxx.com because we don't explcitly set the cookieDomain property in the cookies and so the browser will automatically associated it with api.yyy.com

Thanks <@498057949541826571> !
Just to ensure that I understand 
1. Application runs on `yyy.com`
2. On click of "Login" button on `yyy.com`, the user gets redirected to `identity.xxx.com`
3. User enters his email, gets redirected to his SAML IdP, completes the authentication and comes back to `identity.xxx.com`.
4. At this point, when redirecting back to `yyy.com`, you suggest that I send the jwt in the query string?
5. After coming back to `yyy.com`, a request is made to `api.yyy.com` and the jwt is verified and a new session is created with a new access and refresh token.

Another slightly unrelated question. So currently we have the supertokens website domain as `identity.xxx.com` and here we use the supertokens' frontend sdk. Do you suggest we use the sdk on `yyy.com` also? For session management? Although no real authentication will happen on `yyy.com`

And yes, you can use our SDK on yyy.com as well for sessions, but it’s not really necessary. But I would recommend it

Thank you very much! Saved me days of hard work.