On this page
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 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:
- 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
- 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 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 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:
- 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|
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).|
Customer Hosted Sign-In Widget
|Okta Sign-In Widget version 7+: |
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:
|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:
|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|