Recent Upgrade to OIE, receiving "Client specified not to prompt, but the user is not logged in" after successful Authn and authorize calls


We recently upgraded to OIE in our lower environments, and after going through the checklist, ensuring we weren’t using any of the deprecated functions etc in the sign-in widget (embedded), we upgraded. However, now we are unable to log in to the application.

It is a vuejs application which is still in version 2 for vue for the moment, using okta-vue and okta-authjs. We have the sign-in widget embedded, and do not currently use a refresh token. I have tried in incognito mode in chrome enabling third party cookies, but to no avail.

I am getting successful responses for both the /authn and /authorize calls, but I never get to the resolve for showSignInAndGetTokens, instead it is hitting the afterError handler with OAUTH_ERROR “The client specified not to prompt, but the user is not logged in”.

I have tried a number of solutions, including upgrading versions of the sign in widget and okta-auth-js, fiddling with configurations, etc. We do not have MFA enabled, and no code changes to our login components, just the OIE upgrade.

Has anyone else hit this? Any suggestions on what I might need to change to get this to work? Trying to avoid a gigantic adjustment but trying to just determine what is necessary to get this working, and havent had much luck scouring the forums and stack overflow yet. Thanks!

One note, the issue seems very similar to this one showSignInToGetTokens promise never resolves · Issue #2622 · okta/okta-signin-widget · GitHub - the promise never resolves.

If the widget is pointing to OIE, does it have to have interactioncodeflow turned on?

If you have an Authentication Policy for the target application configured that will require the user to provide an additional factor (one that is not required in the Global Session Policy), then you can encounter this error in between the primary authentication flow used by Okta Classic orgs (/authn) and when the widget then tries to use the sessionToken (returned in the response from /authn) in the /authorize request to your app. As the sessionToken does not prove that the user was able to meet the requirements for the second policy layer, the user would have to be prompted (for an additional factor, for instance), but prompt=none is being sent in the /authorize request, preventing this prompt from occurring and resulting in this error message.

If you are in an Okta Identity Engine org, this limitation does not exist as long as Interaction Code Flow is enabled (as in, a self-hosted widget will be able to evaluate both types of policies).

Otherwise, you need to ensure your application redirects to Okta without prompt=none to ensure that the application level policy (Authentication Policy in OIE) can be evaluated