Okta Sign-In Widget (OIE) does not trigger activation flow for PROVISIONED users — shows error instead of sending email code

Questions
1

Environment:

  • Okta Identity Engine (OIE)
  • Okta Sign-In Widget (embedded mode)
  • useClassicEngine: false
  • useInteractionCodeFlow: true

Background

We have an embedded Okta Sign-In Widget configured for OIE. We are trying to handle users in PROVISIONED status specifically, users who have signed up, but not completed the full flow.

Expected behavior

When a PROVISIONED user attempts to log in through the widget, we expect the widget to automatically detect the user’s status and transition into the account activation flow, sending a verification code to the user’s email and prompting them to enter it, rather than displaying an error.

Actual behavior

The widget does not redirect into any activation flow. Instead, the user receives an error message and is unable to proceed. No activation email is sent.

const config = {
issuer: ‘https:///oauth2/default’,
clientId: ‘’,
redirectUri: ‘’,
useClassicEngine: false,
useInteractionCodeFlow: true,
features: {
registration: false,
},
}

What we have tried

  • Setting flow: ‘unlockAccount’ in the widget config, the network tab shows a 200 response from the widget but no activation email is delivered. We also recognize this may be the wrong flow for PROVISIONED status (vs LOCKED_OUT).
  • Setting the flow to login and also removed the flow key entirely, and we are just getting “Unable to sign in” with a PROVISIONED user.
  • Confirmed the user is PROVISIONED by querying the Okta Users API directly (GET /api/v1/users/{email}), which returns the user with status: “PROVISIONED”.

Questions

  1. Is the Okta Sign-In Widget in OIE expected to automatically handle PROVISIONED users by triggering an activation flow, or does this require additional configuration (e.g., a specific Sign-On Policy rule)?
  2. If automatic handling is supported, what widget config or Okta policy settings are required to enable it?
  3. If it is not automatic, what is the recommended approach for prompting a PROVISIONED user to activate their account through the embedded widget?

image
image858×802 32.5 KB

2

Hi sebasrios,

Can you provide more information on how the account is being created?
I assume this is being done from the Management API (/api/v1/users) ?

For idx self service registration flows typically a user account is created during that flow. The embedded widget in both confidential and public apps supports this.

For idx integrations that use a confidential application (Web) it is possible to start the idx flow with an activation_token. So a user could be created with the Management API and then activated which will either send an email with the activation_token, or return it directly from the API call. That can be used to the start the idx login.

For idx integrations that use a public app (SPA), this is not possible. Only self service registration flows are supported.

4

Hi eric!

Thanks for clarifying. To answer your questions:

  1. Users are being created through the Okta Sign-In Widget itself using the built-in registration/signup flow, we are not calling the Management API (/api/v1/users) directly to create accounts. The widget is initialized with a SPA (public client) OIDC app using the client ID and useInteractionCodeFlow: true.

  2. Given that, we believe we’re in the self-service registration path you described. However, we are still encountering users who end up in PROVISIONED status and are unable to log in through the widget, they just get an “Unable to sign in” error with no activation triggered.

Our questions given this context:

  • Is it expected that a SPA + widget registration flow can produce users in PROVISIONED status (e.g., if they abandon mid-enrollment)?

  • If so, what is the recommended way to handle re-activation for these users through the embedded widget, given that activation_token is not supported for public clients?

  • Is there an OIE policy or Sign-On Policy rule that would allow the widget to detect a PROVISIONED user and re-trigger the enrollment/activation flow automatically?