Okta Identity Engine overview

Identity Engine

Okta Identity Engine is a new authentication pipeline that provides valuable new features and a more flexible approach to your auth needs. This article provides a high-level introduction.

This page discusses the following:

• New features Identity Engine brings to the table
• The deployment models that use these features
• Changes to the documentation experience to support Identity Engine

Note: If you're an admin, or are looking for product docs related to Identity Engine, see the Identity Engine Get started page (opens new window).

Identity Engine new features

Identity Engine unlocks many new capabilities.

App context in email templates

Identity Engine makes the app context available when a user enters an authentication flow. Find context variables in our email templates. These variables allow customers to dynamically customize email style and content based on the app that triggers an email notification.

See Customize email notifications > Use app context.

App intent links

App intent links are used to signal intent to access an app. These links are protocol-specific endpoints that you can use to initiate a sign-in flow to an app. Both Identity Provider and Service Provider initiated flows are supported.

Example app intent link for a SAML application: http://{yourOktaDomain}/app/mysamlapp_1/{appInstanceID}/sso/saml

Before Identity Engine, these endpoints were accessible only with a session. Unauthenticated traffic was redirected to a centralized sign-in page (/login/login.htm) with a fromUri that represented the app that was originally attempted (the app intent link). This occurred before the request was assessed for rate limiting. A session was established and the request was processed.

The user was then redirected to the relevant app intent link through an intermediate redirect to the generic app SSO endpoint (/app/{app}/{instanceId}/{linkName}). The app intent link endpoint validated that the user was assigned to the app, and then enforced the app sign-on policy.

Identity Engine changes the way Okta processes these requests. It no longer forwards requests to the centralized sign-in page (/login/login.htm). Instead, the app intent links location hosts the widget/sign-in experience for the app that the user is attempting to access.

Then, Identity Engine evaluates the Global Session Policy, authentication policy, and all other policies relevant to the sign-in experience. Each app intent link is responsible for hosting the sign-in experience on Identity Engine. Because of this, they share a common app intent link rate limit bucket/group similar to what exists for the centralized sign-in page on Classic Engine.

Authentication policies

Authentication policies are security policy frameworks (opens new window) that allow organizations to model security outcomes for an app. These policies are shareable across applications. For example, you can automatically step up authentication to a strong non-phishable factor when elevated risk is detected. Also, Identity Engine allows you to create flexible apps that can change their authentication methods without having to alter a line of code.

• Configure a global session policy and authentication policies

• Authentication policies (opens new window)

• Policies (high-level concept)

CAPTCHA

CAPTCHA is a well-known strategy for mitigating attacks by bots. Identity Engine offers integrations with market-leading CAPTCHA services for registration, sign-in, and account recovery.

Okta only supports the following CAPTCHA services:

• hCAPTCHA (invisible) (opens new window)
• reCAPTCHA v2 (invisible) (opens new window)

Note: Using any other CAPTCHA type could lead to lockout. Contact Okta support (opens new window) if lockout occurs.

You can use either hCAPTCHA or reCAPTCHA with the redirect or embedded authentication deployment models. See Okta deployment models.

If you use the Sign-In Widget SDK (opens new window), CAPTCHA works out of the box. If you use any other Okta SDK (opens new window), you need to implement CAPTCHA. See CAPTCHAs (opens new window).

Interaction Code grant type for embedded authentication

To enable a more customized user authentication experience, Okta introduces an extension to the OAuth 2.0 and OpenID Connect standard called the Interaction Code grant type. This grant type allows apps using an embedded Okta Sign-In Widget and/or SDK to manage user interactions with the authorization server directly, rather than relying on a browser-based redirect to an authentication component (such as the Sign-In Widget).

Authentication deployment models

You can divide the Identity Engine deployment model for user authentication into three approaches:

• Okta-hosted (redirect) Sign-In Widget: Use the redirect (Okta-hosted) Sign-In Widget to authenticate your users, then redirect back to your app. This is the recommended approach as it's the most secure and fastest to implement.
• Embedded Sign-In Widget: Embed the Sign-In Widget into your own code base to handle the authentication on your servers. This provides a balance between complexity and customization.
• Embedded SDK-driven sign-in flow: Use our SDKs to create a custom authentication experience. This option is the most complex and leaves you with the most responsibility, but offers the most control.

See Okta deployment models — redirect vs. embedded for an overview of the different deployment models, and see Sign users in for implementation details.

SDKs and sample apps

Okta has a host of SDKs available for integrating new Identity Engine features into your apps using Okta deployment models. There are also sample apps to show them in action.

• Browse our SDKs and samples
• Set up and explore our Identity Engine sample apps

Identity Engine versus Classic Engine documentation approach

In our documentation, Okta is moving towards supporting Identity Engine by default, while still providing information for Classic Engine users.

• Pages and page sections covering features that only work in Identity Engine have a blue Identity Engine banner at the top.
• Content that works in both Identity Engine and Classic Engine have no banner. Any slight differences are covered in the page text.
• Content written for Classic Engine that won't work in Identity Engine has a note at the top that explains what the issue is, and, if appropriate, where Identity Engine users can go to find support.
• For guides that were extensively updated to support Identity Engine, Okta keeps a Classic Engine version available if needed.

Note: See Identify your Okta solution (opens new window) to determine your Okta version.

Access and upgrade to Identity Engine

On March 1, 2022, all new Okta orgs are Identity Engine orgs, so that all new customers can take advantage of the new features.

If you're a Classic Engine customer who wants to upgrade their apps to use Identity Engine, go to Identity Engine upgrade overview.

For Classic Engine customers who don't yet want to upgrade, your existing functionality continues to work for now, including your Classic Engine org, v1 API, and SDKs.