Okta API to inject session cookie into the browser is not working in IE 11
We are using Okta API to inject cookie into the browser to create Okta session for a user when user logs in to the application. It is working fine in Chrome and Mozilla browsers but it is breaking in IE 11 where Okta session was not getting created in this version of IE. We are using the below API to inject Okta session cookie into the browser : Add image tag with session cookie image URL(http://developer.okta.com/docs/examples/session_cookie.html#add-image-tag-with-session-cookie-image-url) But after adding the Okta site URL into the list of trusted sites into the "Secuirty" tab of IE 11 "Internet options", this API started working and Okta session was injected in IE 11. Could you please check what is the issue? Does this API supports IE 11? As this is working fine in IE 9.
This flow is now deprecated as some major browser vendors such as Safari block cookies from 3rd-party sites by default. Please use an alternative flow as browser vendors are increasingly blocking cookies from 3rd party sites by default
Could you please suggest any alternative approach for accomplishing this? Our production application is dependent on this API. We do not want users to see the Okta URL or any processing to be shown in the browser. Thanks, Ankit
Can you describe how your application login works right now and how having the okta security session comes into play? I'm left to assume that if you are concerned with establishing an Okta security session you intened at somepoint to send the user through to an Okta embed link?
I believe for better or for worse the default behavior or web browsers blocking 3rd party cookies is going to require a change in your login approach.
I have a similar configuration, we wanted to have a customized login screen but didn't have the luxury of being able to rewrite the authenticaiton and sessions managment portion of our application. Our application supported SAML for authenication so we take this approach:
User provides credentials to our customized login form
Credentials are validated using the session API (needs to swtich to the authenitcation API)
The resulting cookieToken is returned as part of the response
The user-Agent is then 302 redirected to the Okta application embed link with the cookieToken sent through as the onetimetoken parameter value
Okta accepts the cookieToken as authentication and the okta security session is established
The normal interstitial page is present for a brief period as the SAML assertion is generated and the user-Agent is sent back to the SAML consumer service on the originating platform where the SAML assertion is used to establish the users session
Thanks a lot for the response and the alternative.
Below is the approach which we are followng to establish the user Okta session :
1. User logs in to application by entering username/password. 2. User is authenticated against Okta using authenticate API which will return the one-time cookieToken to establish the session. 3. If the response returned by the Okta authenticate API is success, we are creating the application session and storing the cookieToken in user extended properties and redirecting the user to a page. 4. On this page we are reading the one time cookie token of a logged in user from user extended properties and calling the Okta login/session API(http://developer.okta.com/docs/examples/session_cookie.html#add-image-tag-with-session-cookie-image-url) inside the hidden img tag. After the page has loaded the user will have an active session with Okta and will be able to SSO into their applications. 5. Using this approach the interstitial page will not be shown to the user as our business will mark it as a bad user experience. This aproach is already running in our production application servers but we found recently that it is breaking in IE 11.
So is it possible to still go ahead with this approach in future?