Deployment Model - Embedded Okta Sign-In Widget (SIW)
Last Updated:
Telemetry detected an embedded Okta Sign-In Widget is actively in use (CUSTOMER_HOSTED_SIGN_IN_WIDGET). The upgrade can proceed. Post-upgrade, the embedded widget continues to operate in classic mode with no immediate changes required. To take advantage of OIE-only features — such as application sign-on policies, passwordless authentication, and Profile Enrollment — the widget must be updated to the latest version and configured to use the Interaction Code grant type.
Known Impacting Gap — Self-Service Registration will break after upgrade: If features: { registration: true } or features.registration = true is present in the widget configuration, Self-Service Registration will stop working after the upgrade to OIE.
This is not automatically detected by telemetry — it requires a manual review of the widget configuration code. Additionally, setting useClassicEngine: true will also disable SSR post-upgrade.
If the widget cannot be updated and Self-Service Registration is still required, a secondary application configured for Identity Engine will be needed.
Applies To
- CUSTOMER_HOSTED_SIGN_IN_WIDGET
- Upgrade Eligibility: Customer Consent Required
After the upgrade, the embedded widget operates in classic mode. Adoption of OIE features requires additional steps post-upgrade.
Experience Impact
The embedded Okta Sign-In Widget continues to authenticate against the Classic Authentication Pipeline after the upgrade. All general Identity Engine feature changes will apply to the org, but will not be enforced at the embedded widget level until the widget is updated to use the Interaction Code grant type.
The following capabilities will no longer function post-upgrade without remediation:
- Self-Service Registration (
features: { registration: true }) — Requires the Interaction Code flow to be configured in OIE. Classic SSR behavior is not carried forward automatically. This must be checked manually in the widget code. useClassicEngine: true— Also disables SSR in the OIE environment. Remove this flag if registration is required post-upgrade.- Deprecated JavaScript methods — Any deprecated methods must be removed. See the developer guide in the References section.
Detecting the Origin of the Sign-In Widget
If the location of the embedded Okta Sign-In Widget is unclear, run the following query in the Okta Admin Console under Reports > System Log:
debugContext.debugData.requestUri sw "/api/v1/authn" and debugContext.debugData.oktaUserAgentExtended co "signin-widget" and debugContext.debugData.origin pr
Results will include the origin domain of the application hosting the widget, helping confirm the location and scope of the embedded integration.
Before the Upgrade
Review the widget code for Self-Service Registration configuration and deprecated methods, then validate the updated widget in an OIE preview environment before upgrading production.
-
Search the widget configuration code for
features: { registration: true }orfeatures.registration = true. If found, plan the Interaction Code migration before upgrading, or have a remediation plan ready for immediately after. -
Check for and remove
useClassicEngine: trueif Self-Service Registration is required post-upgrade. -
Review the widget code against the list of Deprecated Features and JavaScript methods and remove any that are in use.
-
Review Sign-In Widget CSS and i18n customizations. Styling overrides tied to Classic widget DOM structure and any i18n property overrides should be tested in an OIE preview environment to confirm they render correctly post-upgrade.
After the Upgrade
Post-Upgrade Warning — “Remember My Device” behavior: If users have opted in to Remember this device or Don't prompt me again on this device, this behavior can be impacted when authentication policies are updated post-upgrade. Changes to policy rules — such as new factor requirements or updated reauthentication intervals — can invalidate saved device state and prompt users unexpectedly.
Moving to the Okta Hosted Sign-in experience (federation model) is highly recommended to ensure authentication policy changes are handled consistently and to deliver the best end-user experience across the full authentication flow.
When ready to unlock OIE-only features, choose one of the following paths:
- Option 1: Upgrade to OIE Embedded SIW with Interaction Code — Update the widget to the latest version and configure the Interaction Code grant type. This unlocks all OIE features including application sign-on policies and Profile Enrollment.
- Option 2: Shift to the Okta Hosted Sign-in Experience (Recommended) — Moving to the federation model that leverages the Okta Hosted Sign-in framework is highly recommended to optimize the user experience and get the most out of the OIE authentication flow. The Okta Sign-In Widget v3 provides significant extensibility for sign-in page customization without requiring a self-hosted integration.
- Option 3: Migrate to an Embedded OIE SDK — Replace the widget with an Okta Identity Engine SDK for full programmatic control of the sign-in flow.
For a detailed overview of migration paths, see Okta deployment models — redirect vs. embedded.
Related References
- OIE upgrade overview
- Deprecated Features and JavaScript methods
- Upgrade the Okta Sign-In Widget
- Sign-in Widget upgrade guide
- Okta deployment models — redirect vs. embedded
- Custom sign-in page upgrade guidance
- Building a custom sign-in experience with Okta Sign-In Widget v3
- Okta custom sign-in page extensibility with Sign-In Widget v3
AI Code Review Prompt
To help prime an LLM that may be assisting with a code assessment, copy the prompt below and paste it into any AI assistant. Replace [PASTE SOURCE CODE HERE] with the full HTML/JS/CSS of the embedded sign-in page. AI findings are a starting point — verify all results through end-to-end testing before making production changes.
You are an Okta Sign-In Widget specialist. Review this embedded (customer-hosted) sign-in page for OIE upgrade compatibility.
[PASTE SOURCE CODE HERE]
---
WHAT TO CHECK:
Widget version — extract from CDN URL pattern okta-signin-widget/{major}.{minor}.{patch}
< 5.x = legacy (+5 pts) | 5.x–6.x = Classic-era (+3 pts) | ≥ 7.x = OIE-capable
useInteractionCodeFlow: true — if absent, flag as required for OIE (+1 pt)
Deprecated feature flags (+1 pt each if present):
features.idpDiscovery, features.rememberMe, features.autoPush, features.smsRecovery,
features.callRecovery, features.webauthn, features.selfServiceUnlock,
features.multiOptionalFactorEnroll, features.registration,
features.showPasswordToggleOnSignInPage, features.scrollOnError,
features.skipIdpFactorVerificationBtn
High impact (+3 pts each): registration: { | .setCookieAndRedirect( | processCreds:
Medium impact (+2 pts each): .preSubmit( or .postSubmit( | parseSchema:
Low impact (+1 pt): idps: [ (still works in OIE, no change required)
CSS rules targeting #okta-sign-in or .auth-container: 1–10 = +1 | 11–30 = +2 | 30+ = +3
i18n overrides (config.i18n or englishLanguage[): +1
Event hooks (oktaSignIn.on(): +1
EFFORT TIER:
0 = DEFAULT (no findings) | 1–4 = LOW | 5–9 = MEDIUM | 10–14 = HIGH | 15+ = CRITICAL
---
OUTPUT:
For each finding: matched line with ±1 line context, OIE impact explanation, and remediation action.
Close with a scored summary table, effort tier, and priority-ordered action list.
Cite links from the reference list below where applicable.
---
REFERENCE LINKS:
Widget upgrade guide: https://developer.okta.com/docs/guides/okta-sign-in-widget-upgrade/
Upgrade the Okta Sign-In Widget: https://developer.okta.com/docs/guides/oie-upgrade-sign-in-widget/-/main/
Deprecated features and JavaScript methods: https://developer.okta.com/docs/guides/oie-upgrade-sign-in-widget-deprecated-methods/main/
setCookieAndRedirect: https://developer.okta.com/docs/guides/oie-upgrade-sessions-api/main/
Registration block: https://support.okta.com/help/s/article/OIE-Incompatible-FF-SELFSERVICEREGISTRATION
Custom sign-in page upgrade guidance: https://help.okta.com/oie/en-us/content/topics/identity-engine-upgrade/self-service/custom-sign-in-page.htm
OIE upgrade overview: https://developer.okta.com/docs/guides/oie-upgrade-overview/main/
Deployment models — redirect vs. embedded: https://developer.okta.com/docs/concepts/redirect-vs-embedded/