SenthilS.81421 (Customer) asked a question.
Our application runs on - https://app.mydomain.com
I have a federation setup as a service provider for a company (abc.com) with assertion URLs like mydomain.okta.com. After the SAML handshake, we call mydomain.okta.com/session/me endpoint and later mydomain.okta.com/authorize endpoint to get access token based on sid cookie. This is the cross-site call., we are trying to avoid.
As a suggested solution with vanity domain, I have set-up a vanity domain like sso.mydomain.com. Will this work without any change in the existing federation setup? The answer is NO, its not working.
When we tried with vanity domain setup(sso.mydomain.com), we got error in sso.mydomain.com/session/me (404) endpoint & in sso.mydomain.com/authorize (401) endpoint. Because, there were no sid in the cookie for both the calls. The sid cookie was created under mydomain.okta.com, as that was the end of SAML handshake calls.
How can we get the token in the SAML federation workflow? What is the correct way to utilize vanity domain to avoid 3rd Party cookie issues in the modern browser without changing the browser settings?
Hello @SenthilS.81421 (Customer) Thank you for posting on our Community page!
There was a similar question on this matter, please see below:
https://support.okta.com/help/s/question/0D54z0000A5vfTECQY/third-party-cookies-disablement-in-google-chrome?language=en_US
Additionally if you need further assistance we recommend to leverage the Okta Developer forums for this type of questions and take advantage of their expertise.
https://devforum.okta.com/
Thank you for reaching out to our Community and have a great day!
--
Join the Ask Me Anything online event on June 13, 2024 to discuss the new Govern Okta Admin Roles feature with our Experts