We have an Okta integration for our application. We created a developer account back in 2020 and everything worked fine. Unfortunately, old developer accounts were disabled. We didn’t receive any email about this, and we can’t log in to the old account anymore.
So I created a new Integrator account. I no longer have access to the old developer account and therefore can’t migrate or copy any settings. Now something seems to be missing: I created a new application with a new Client ID, new Secret, and new Domain. Redirect URIs for sign-in and sign-out are configured.
Everything looks like I remember it, but when I try to log in from our application, we get the following error message:
“Bad request” “Error: The client specified not to prompt, but the user is not logged in.”
I know our software works—our customers are using it—so the problem must be in the Okta settings.
I searched through all settings, but I can’t find any client option like “do not prompt”.
This error message indicates that your OIDC application is sending a /authorize request to Okta with the prompt parameter set to none. So right now, your application is instructing Okta to NOT prompt the user for authentication during the /authorize call, typically with the assumption that the user already has an active Okta session. Since this seems to have worked previously, I’m guessing there’s a configuration mismatch in your org, not a direct issue with your application.
If your Developer Org was created back in 2020, it was likely an Okta Classic org. In contrast, all Integrator Orgs are on Okta Identity Engine. This impacts a number of things related to auth; in particular, there are new Authentication Policies in OIE that can be assigned to applications so, for example, individual applications can challenge for additional factors or re-authentication (in Okta Classic, this was configurable on the Sign On tab for the application itself).
So my questions are:
What Global Session Policy is the authenticating user encountering and what does it challenge for (e.g. 1 factor or 2 factors)?
What Authentication Policy is assigned to the target application, and what does that policy challenge for? Does it have stricter requirements than the Global Session Policy?
I checked the policies and set global policy and app policy to authentication by password without MFA.
And I compared log output from my testsystem with a customer system. Customer is using Okta since several years without problems, my testsystem shows the error message. Both log entries include the prompt=none: