<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeKnowledge Base

Deployment Model - Embedded SDK

Last Updated:

Administration

Telemetry detected a custom sign-in experience using an Okta SDK (CUSTOMER_HOSTED_AUTHN_SDK) is actively in use. No changes are required to proceed with the upgrade. The classic SDK will continue to operate post-upgrade in classic mode. To take advantage of Okta Identity Engine sign-in capabilities, the SDK must be updated to an OIE-compatible version.

What this means for the upgrade: The upgrade can proceed without modifying the existing SDK integration. Post-upgrade, these sign-in flows continue in classic mode on the Identity Engine org. New OIE features — including application sign-on policies, passwordless, and Profile Enrollment — will not be available to this sign-in experience until the SDK is updated.

Applies To

  • CUSTOMER_HOSTED_AUTHN_SDK
  • Upgrade Eligibility: Eligible with Warning

The warning reflects the effort required to adopt OIE functionality post-upgrade. The upgrade itself can proceed without SDK changes.

Experience Impact

The org uses a customer-hosted authentication experience built on the Okta Classic SDK. After upgrading to Identity Engine, these flows remain on the Classic Authentication Pipeline. New OIE capabilities are not available until the SDK is updated to an OIE-compatible version.

Known areas requiring verification before upgrading:

  • Account Activation flow — Email templates that include fromURI to redirect back to the custom sign-in application should be tested to confirm they still route correctly post-upgrade. Confirm whether the activation payload passes an activationToken into the custom SDK flow, and whether any custom or external email is in use. See Activation Templates.
  • Custom Password Recovery — If a custom recovery flow passes a recoveryToken to the SDK, end-to-end testing is recommended before upgrading production. See Recovery Templates.
  • Email Template modifications — Activation and Recovery templates modified to divert to the custom embedded application should be verified post-upgrade.

Before the Upgrade

No changes are required to the SDK integration. Verify Account Activation and Recovery email templates and Custom Password Recovery flows in an OIE preview environment before upgrading production.

  • Test Account Activation and Recovery email templates for fromURI redirects that target the custom sign-in application.
  • Test any Custom Password Recovery flows in an OIE preview environment.

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 features for this sign-in experience, choose one of the following paths:

  • Option 1: 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 2: Update to the Okta Identity Engine SDK — Replace the Classic SDK with the OIE-compatible SDK for your language or framework. This enables full access to OIE sign-in capabilities while retaining the embedded experience.

  • Option 3: Adopt the Direct Authentication API — For native or API-driven flows, the Direct Authentication API provides a supported path to OIE capabilities without a full SDK migration.

For a detailed overview of migration paths, see Okta deployment models — redirect vs. embedded.

Related References

Recommended content

Still looking for help?
Loading
Okta Support - Deployment Model - Embedded SDK