SessionToken does not override existing session cookie

We created a new auth code service and we’re noticing different behavior from another (what we think is) identically configured service. In the new service when a user logs in using the latest version of the widget they establish a session cookie with our custom okta domain. That’s great but when we then attempt to login with a different user from the same browser, the id token returned from the /token request is for the previous user we logged in with. So it seems okta is overriding the sessionToken that was created via the widget with the session cookie. On an existing service that seems identically configured and using the exact same code on our end, we see the 2nd login being successful with the token being returned containing the user details of the 2nd login. Does any know know where that behavior is controlled? Thanks!

It sounds like you might be running into a behavior where when an /authorize call is made that contains a newly required sessionToken, but the browser also has an active Okta session cookie, then the tokens returned are for the user associated with the session cookie?

If so by default the sessionCookie will take precedence over a supplied sessionToke. If you would like to change this behavior you will need to open a case with support to enable this feature for your Okta Org.

You might also want to consider logging a user out if this application will run on a community system to make sure active sessions are not left over in the browser.

1 Like

Hi Erik,

Thanks for your help! I will reach out to support. Do you know why i would see the opposite behavior by another application / auth server in the same tenant? I don’t understand why it works differently across services. Was this behavior changed at some point recently for new applications? I could log the user out but it’s going to be a pain to have to redirect the user through that flow before showing them the login page each time.


It could be that the environment where you don’t see this already has this feature enabled.
I would mention both Orgs in the case so the features can be compared and check if one or the other either had it added at some point in time or removed.