Okta sign in widget logs me out when the 3rd party cookies are disabled

Questions
1

Hi,

I am working on the fixes for apps which use 3rd party cookies to avoid any potential fallout when Googe deprecates 3rd party cookies this year.
I have 2 applications using Okta sign in widget. I have disabled 3rd party cookies in the browser. One application stays signed in however the other application for a brief moment logs me in and again logs me out of the app by redirecting to the login screen.

Any idea as to why one app stays signed in while the signs me out.

Thank you!

2

Are you referencing the Okta-hosted sign-in widget, or a self hosted sign-in widget, or both?

3

It’s a self hosted sign-in widget however the validation is done by Okta

4

Well yeah, if it’s the self hosted widget and you are using OIE (right?) then the interact flow (IDX) is used to pass credentials, do MFA, and then Okta issues an ID token/access token.

In your scenario it says the second app logs you out and redirects to the login screen. My first thought is that the second app has a problem. It is acting like a session cookie (its own) was never set. It is also acting like it triggered a universal logout and clear the session that the user had with Okta.

The first app wouldn’t notice unless it’s session expired. Can you clear the session cookie for the first app and see if you get SSO or are back to a login screen?

5

Rereading the original question, are the two applications sharing a widget or do they both embed the widget? I’ve used this both ways.

If you are using two widgets (one in each app) the IDX flow tries first with a third-party cookie before it presents a login screen. At least I think it still does that, I’ll have to dig a little to check. Without seeing what you are seeing, I can imagine that the second app flickers because it first tries sending the idx cookie, and that is what you see that makes you think you are logged in? But then that fails so it flickers again and you land on the login page. Of course I’m just guessing at scenarios here, I can’t see it.

So let me ask you this: if you login to app #2 after you land on the ultimate login page, what happens? Does it stay logged in?

6

Hi,

Each app has its own widget. I have cleared the session for the first app however it still stays signed in. Is there way we can connect over the phone? I can explain better.

Thanks,
Ashith.

7

Hi Ashith,

I am not Okta support, I work for Okta education services :slight_smile: But I do try to help.

The third-party cookie thing has been bothering me for a while, and I was actually teaching the Customer for Identity for Developers class when I saw your questions, so I decided to do some testing. I implemented several scenarios because I wanted to test a statement in some of the documentation about using the redirect flow. But it is as I thought, the statement only applies to the old widget using the AuthN API, not the new Interaction flow (IDX).

Side note: third party coodies were not an issue in the Okta Classic engine because there was a way to pass through Okta simply to pick up the session cookie (see the deprecated Sessions API endpoints).

So,

  1. For OIE the embed widget always uses the interact flow (IDX) using API calls, not a redirect.
  2. The flow sets the ‘idx’ cookie, but it is a third-party cookie because it came from an API call.
  3. Even if you force a redirect (I did in a SPA just to try it there too), the cooke still came via the API, so it is still a third-party cookie.
  4. If you leave a SPA or close a traditional web app, the trainsient cooke is deleted so you are always disconnected.
  5. If third-party cookies are enabled, then any other app in the same browser sess the cookie and you have SSO because the IDX flow first request checks the status before displaying the login form by sending the cookie.
  6. If you disable third-party cookies, no Okta SSO is possible because the ‘idx’ cookie is never sent in the request. Every app is forced to read and authenticate the user.

I was hooked by the scenario where the second app thinks you are logged in but then logs you out, but I suspect something else is just making it look this way. You really don’t have a session cookie, so SSO cannot work.

Let me know if this makes sense :slight_smile:

1 Like
8

Hi Joel,

Thank you for sharing your valuable insights. The issue has been resolved. I used the latest version of the okta cdn. So now even if the 3rd party cookies are disabled the user is not kicked out. Appreciate your help.

Also, I now have another issue related to capturing the error handle when the okta sign in widget fails. In this instance I need to handle the 401 (Unauthorized) error once the Api fails to return any records due to invalid credentials. Below is the code snippet.

oktaSignIn.renderEl(
{ el: ‘#okta-login-container’ },
function (res) {
if (res.status === ‘SUCCESS’) {
res.session.setCookieAndRedirect(redirectUrl + ‘?username=’ + res.user.profile.login);
}
},
function error(err) {
if (err.toLowerCase().indexOf(substring) >= 0)
// handle errors as needed
alert(‘in’);
}
);

9

Cool on the first part! I was testing this again because I found out that if you ask for a refresh token the widget is supposed to use the refresh token instead of the idx cookie on the subsequent calls bypassing the third-party cookie problem. But that should only work for a single app (like a portal), since the token isn’t passed around.

The code that you are showing won’t work, because the error handler for the widget only is triggered for configuration errors. The widget is probably absorbing the 401 and just cycling through again.

10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.