Okta deployment models — redirect vs. embedded

When you develop applications that require the customer to sign-in and authenticate, the user authentication deployment model is a critical design consideration. In this article we look at the authentication options that Okta provides and what the differences are between them.

Redirect vs. embedded

Okta's deployment models can be broadly divided into two approaches:

• Redirect authentication: A user sign-in flow that grants authentication control to Okta by redirecting to an Okta hosted sign-in page using open protocols like OAuth 2.0 and SAML.
• Embedded authentication: A user sign-in flow where the application retains authentication control, without redirection to Okta, using a client-hosted embedded Sign-In Widget, the SDKs, or directly with API calls.

What deployment model or authentication approach you choose depends on your implementation requirements and client application. In general, the method of delegating user sign-in interaction (redirect authentication) is generally preferred for many reasons that span from security to user experience.

Use this table and the subsequent sections to better understand the differences between redirect authentication and embedded authentication, and what flow works best for your application implementation:

Requirement	Redirect authentication	Embedded authentication
Client application requires a redirect to an Identity Provider.	✅
Client application owns the authentication and registration process.		✅
Client application owns user remediation (communication with Identity Server).		✅
Client application needs to support external Identity Providers, authenticators, or claims providers.	✅	✅
SSO is implicit (if an Okta session is created, SSO is implemented for other resources).	✅
Full control over application customization is a key requirement.		✅
Client application requires centralized session management across applications.	✅

Note: To get started with implementing a user sign-in flow, see Sign users in. Read on for more guidance in choosing what model is right for you.

Redirect authentication

Redirect authentication through the Okta-hosted Sign-In Widget is considered the easiest and most secure means of integration. This is because the Sign-In Widget itself is hosted by Okta, maintained by Okta, and kept secure by Okta. The Okta-hosted Sign-In Widget is recommended for most integrations.

The user or system is redirected to Okta for credential verification and is then provided authenticated access to the client application and other Service Providers. When a user signs in to the client application, they are redirected to Okta using a protocol like SAML or OpenID Connect (OIDC). After the user signs in (based on policies that are configured in Okta), Okta redirects the user back to your application. You can customize your app's domain and the Sign-In Widget style to match your brand.

Note: Single Sign-On (SSO) is supported for redirect authentication. That is, Okta may create a session (based on the Okta policies, for example), and then other integrated applications can use SSO to sign users in.

Consider, for example, when an organization uses Okta as its Identity Provider. A user tries to access the organization's on-site or cloud-based application (for example, email) and is redirected to the corporate Identity Provider, Okta, to provide sign in and authentication. After the user is authenticated, Okta provides a token or assertion to the original application to grant the user access. Okta also creates an Okta session for the authenticated user. Using SSO with this existing Okta session, the user is automatically signed in to any other of the organization's Service Provider applications (CRM, IT, HR, and so on).

The interactions and communication with the Identity Provider are as follows:

Redirect summary

• Works out of the box
• Easy to use with no maintenance and no updates
• Hosted and secured by Okta
• XSS (opens new window) (cross-site scripting) attacks on your application doesn't affect the sign-in experience
• Easy to integrate manually or with a generic OIDC client
• Extremely customizable through HTML, CSS, and JavaScript
• Complex logic changes that require source code access are limited
• The user is redirected out of the application to Okta, and then back to the application.
• Handles most client deployment requirements

Use the redirect deployment model when

• you have multiple applications or use third-party applications and need SSO.
• you want Okta to control the authentication flows through policy configuration.
• you want Okta to control upgrades to take advantage of new functionality.
• your application already uses an OAuth 2.0 or SAML provider to sign in.

Embedded authentication

Embedded authentication is the process of authenticating user credentials directly at the client application site using an embedded Sign-In Widget, authentication SDK, or direct API calls. Redirection to Okta isn't required. The client application's code determines the methods and processes necessary to authenticate, and then uses SDKs to validate the credentials. Client applications create their own application sessions for user access, and may also exchange tokens with a Security Token Service (STS) to provide SSO access to other Service Providers (CRM, IT, HR, and so on). Using this deployment model, the client’s sign-in page can render native user experiences and use native platform APIs.

Note: We strongly advise against using WebViews for authentication on mobile apps as this practice exposes users to unacceptable security risks. See OAuth 2.0 for Native Apps. Consider using Okta's native SDKs instead.

The customer-hosted embedded Sign-In Widget is considered the best balance of flexibility and effort to integrate, and is recommended if an integration requires a deeper level of customization than is available through an Okta-hosted Sign-In Widget. The embedded Sign-In Widget works by embedding the open source Okta Sign-In Widget (opens new window) into the application's web page. The Sign-In Widget is built and updated by Okta, uses industry best practice security design, and is added to a page with a few lines of HTML/JavaScript. You can load it directly from the CDN, NPM, or build from source.

The look and feel is customized directly through HTML/CSS/SASS and JavaScript. Features are configured within the Admin Console and enabled through JavaScript.

The SDK and API options allow for even more control over customization of the entire experience, but they do have their drawbacks — they are more complex to implement and maintain, and the security is your responsibility. They are available if you need that level of customization.

The detailed interactions at the client level between a client’s authorization server and resource owner are provided below:

Embedded summary

• Moderate maintenance may be required. If using a CDN, maintenance is more limited as it is being kept up-to-date by Okta. NPM packages a specific version of the Widget, which means that it may need to be updated in the project periodically. Customized or local versions of the Sign-In Widget source code require regular updating.
• A great level of source code customization control is offered while being drastically easier and more secure than building from scratch.
• There is a slightly increased risk in security due to Okta not being able to guarantee that the Sign-In Widget has been implemented correctly. Specifically, the application code may have the ability to access the credentials that the user has entered into the Sign-In Widget, which need to be kept secure.
• XSS (cross-site scripting) attacks on your application may result in stolen sign-in credentials.
• A higher level of effort to integrate and maintain is required compared to the Okta-hosted Sign-In Widget.
• The user is kept in the application, which reduces redirects to and from Okta.

Deployment models and the Authentication API

The following table details the configurations that define which Authentication API (either Okta Classic Engine or Okta Identity Engine) your application is using based on your deployment model.

Deployment Model	Classic Engine Authentication API	Identity Engine Authentication API
Redirect: Okta Hosted Sign-In Widget To verify that the redirect deployment is used in your application code, check that you are using one of these SDKs: Android (opens new window), Angular (opens new window), ASP.NET (opens new window), iOS (opens new window), React (opens new window), React Native (opens new window), Vue (opens new window)	The API type depends on your org configuration. (opens new window)	The API type depends on your org configuration (opens new window).
Embedded: Customer Hosted Sign-In Widget	Okta Sign-In Widget version 7+: useClassicEngine set to true. Okta Sign-In Widget version < 7: Classic Engine used by default.	Okta Sign-In Widget version 7+: Identity Engine used by default. Okta Sign-In Widget version < 7: useInteractionCodeFlow set to true.
Embedded: SDKs	To verify that the embedded deployment is used in your application code, check that you are using one of these Classic Engine SDKs: Java (opens new window), JavaScript (opens new window), .NET (opens new window), Swift (opens new window)	To verify that the embedded deployment is used in your application code, check that you are using one of these Identity Engine SDKs: Android (opens new window), ASP.NET (opens new window), Go (opens new window), iOS (opens new window), Java (opens new window), Node.js (opens new window)
Embedded: APIs	Your app is using: Classic Authentication API	N/A

See also

OAuth 2.0 and OpenID Connect Overview