https://supertokens.com/ logo
Title
m

mayankgopronto

12/16/2022, 12:29 PM
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

nkshah2

12/16/2022, 12:33 PM
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

mayankgopronto

12/16/2022, 12:44 PM
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

nkshah2

12/16/2022, 12:45 PM
@rp can help here
r

rp

12/16/2022, 12:48 PM
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

mayankgopronto

12/16/2022, 3:38 PM
Thanks @rp ! 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

rp

12/16/2022, 4:18 PM
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

mayankgopronto

12/16/2022, 5:44 PM
Thank you very much! Saved me days of hard work.
r

rp

12/16/2022, 5:48 PM
Cheers!