https://supertokens.com/
Join Discord
*SAML SSO across different domains* So our supertokens apiDomain is `api.xxx.com` and the front end...
# support-questions-legacy
m
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.
n
Hi @mayankgopronto, 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
m
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?
n
@rp_st can help here
r
ah well yyea.. you are right @mayankgopronto . 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
m
Thanks @rp_st ! 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
r
Yea. Flow is absolutely correct
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
m
Thank you very much! Saved me days of hard work.
r
Cheers!
PreviousNext
Powered by

SuperTokens.com

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

Powered by