I have inherited an older Vuex application (5+ years) that requires moving to the identity engine.
As it stands, a client would log into the company portal, and it would then have links to several microsites. There is no login from our site - widget or otherwise
Along the way my application tries to validate the session with calls to /api/session:
myoktadomain.com/api/v1/sessions/{sessionId}
With the new identity engine, as I understand it - this would change to : myoktadomain.com/api/v1/sessions/me
But that route would also expect me to pass through the IDX cookie value in the headers.
So here’s my dumb question: My application is not on the same domain as the cookie being set (the cookie is a third-party cookie) and therefore cannot be read by the client when trying to make the request.
Am I missing something really obvious about how to validate my session?
Any help is very much appreciated.
Whats your business need to validate the Okta session instead of your application session?
As you saw, in OIE, you cannot use the /sessions/${sessionId} endpoints and can only use /sessions/me, which is intended to be run in the same browser in which the user has (or potentially has) an active Okta session. If you make this call from a domain like example.com, while your Okta org is on myoktadomain.com, then, yes, you would be reliant on the browser not blocking third party cookies.
If you do still need/want to make this request and there is concern about the end-user browser being configured to block third party cookies, our main recommendation would be to configure a custom domain for your Okta org AND host your application from the same domain. That way the Okta session cookie is first party and the /sessions/me request will work when third party cookies are blocked in the users browser. More advice about 3rd party cookies and custom domains can be found here: How Blocked Third Party Cookies can Potentially Impact an Okta Environment | Okta Help Center