Okta Identity Engine release notes (Preview)

Version: 2024.12.0

December 2024

Generally Available

Sign-In Widget, version 7.26.0

For details about this release, see the Sign-In Widget Release Notes.

For more information about the Widget, see the Okta Sign-In Widget Guide.

Okta MFA Provider for ADFS, version 1.8.2

This version includes bug fixes and security hardening.

Okta On-Prem MFA agent, version 1.8.0

This version includes security enhancements. See Okta On-Prem MFA agent version history.

Device assurance OS version update

The following OS versions are now supported in device assurance policies:

  • Android 12, 13, 14, 15 security patch 2024-12-05
  • iOS 17.7.2
  • 18.1.1
  • macOS Sequoia 15.1.1

OAuth 2.0 security for invoking API endpoints

Okta Workflows users can now securely invoke API endpoints using OAuth 2.0 protocols and their Okta org authorization server. Compared with the existing token authorization option, this feature is more secure while also being easier to implement. Add the okta.workflows.invoke.manage scope to any new or existing app integration to make it eligible to invoke your API endpoint. See Invoke a flow with an API endpoint.

Role-based access control for Okta Workflows

As Okta Workflows has the ability to make comprehensive changes both within Okta and out to other connected SaaS apps, access to Workflows was restricted to Okta super admins. This limited the number of users, restricted the ability to scale the use of Okta Workflows, and reduced its overall value to customers.

With role-based access control (RBAC), you can assign Workflows privileges to more users without granting unnecessary access.

To support this feature, three new admin roles are now available:

  • Workflows Administrator: For full-access administration only within Okta Workflows
  • Workflows Auditor: For compliance management with read-only access
  • Connection Manager: For securely handling accounts and credentials

This feature allows customers to expand the use of Okta Workflows beyond super admins, enabling more team members to build and manage Workflows securely and efficiently.

To turn on this EA feature for your org, go to SettingsFeatures in the Admin Console and enable these options:

  • Workflows Access Control
  • Workflow Admin Role
  • Workflows Provisioning

See Access Control.

The addition of the RBAC feature includes four new event types to record related actions in Okta Workflows:

  • workflows.user.role.user.add
  • workflows.user.role.user.remove
  • workflows.user.role.group.add
  • workflows.user.role.group.remove

See the Event Types API.

Okta account management policy

The Okta account management policy helps admins easily build phishing resistance into actions such as account unlock, password recovery, and authenticator enrollment. Using the familiar rule-based framework of an authentication policy, admins can now customize which phishing-resistant authenticators are required when users attempt these common self-service actions. All of the configurations in the authentication policies can now be applied for authenticator management. See Okta account management policy.

Step-up authentication for Office 365

This enhancement enables customers to dynamically prompt for Okta MFA when needed, without having MFA configured in the authentication policy. See Use Okta MFA for Azure Active Directory.

Authentication method chain

With this feature, you can require users to verify with multiple authentication methods in a specified sequence. You can create multiple authentication method chains in an authentication policy rule to cater to different use cases and scenarios. See Authentication method chain.

Polling for Agentless Desktop Single Sign-on and Integrated Windows Authentication

Agentless Desktop Single Sign-on (ADSSO) and Integrated Windows Authentication (IWA) authentication sessions now include polling to reduce the likelihood of service disruptions when bandwidth use peaks. For users authenticating with ADSSO or IWA during peak use periods, this change increases the likelihood that a server will be available to process their authentication request.

Identity Verification with third-party Identity Verification providers

When users take certain actions, Identity Verification enables you to use a third-party Identity Verification provider to verify the identity of your users. Verification requirements and the Identity Verification provider are based on your authentication policies and configurations within your Okta org. Okta supports Persona as a third-party Identity Verification provider. See Add an Identity Verification vendor as Identity Provider.

RADIUS push notifications

The operating system is no longer included in RADIUS push notifications. Customers can contact Okta Support if they need to display this information.

Support for importing Active Directory group descriptions

The descriptions of groups sourced from Active Directory now use their description from AD. These replace any previous descriptions of AD-sourced groups in Okta, which used a pretty-printed version of the distinguished name (DN) instead.

Granular deprovisioning in Microsoft Office 365

You can now deprovision users in Office 365 using multiple methods. See Deprovisioning options for Office 365.

Automatically assign the Okta Access Certifications app

When you assign the super admin role to a user, the Okta Access Certifications app is automatically assigned.

Industry term update in the OIN catalog

The NGO industry term has been updated to Nonprofit Organizations in the Okta Integration Network (OIN) catalog. All published integrations with the NGO designation now have the Nonprofit Organizations designation.

System Log event for emails added to the bounced email list

A System Log system.email.bounce.removal event is now triggered when an API request is made to remove bounced emails (POST /org/email/bounces/remove-list). This request sends a list of emails to a third-party email service to remove the emails from the bounce list. The event is triggered when the API request is made. The event doesn’t indicate when the emails are actually removed by the third-party email service.

Haitian Creole translation for end users

On the End-User Settings page, users can now set their display language to Haitian Creole. See Supported display languages.

Filters for network zones

New filters in the network zones table help admins quickly distinguish between system-defined zones and those they have created. See Manage network zones.

Request access on behalf of another user

You can now allow users to request admin access for other users from their own dashboard. After you enable the option in the access requests conditions that manage admin role bundles, you can grant this permission to all users or limit it to managers only. See Create an access request condition.

Use case selection in the OIN Wizard

Independent software vendors (ISVs) can now select the following use case categories when they submit their integration to the Okta Integration Network (OIN):

  • Zero Trust
  • Identity Verification
  • Identity Governance and Administration (IGA)

See Use case guidelines for the OIN Wizard.

New task for orgs with one super admin

The Tasks dashboard widget and the HealthInsight page now indicate when an org has fewer than two super admins. This helps prevent orgs from losing access to the Admin Console.

Download links for Okta Jira and Confluence Authenticators in Admin Console

The download links for Okta Jira and Confluence Authenticators are no longer available in the Admin Console.

IdP client secret System Log event update

The system.idp.lifecycle.read_client_secret System Log event now includes an API key. The System Log event is triggered when you make a GET api/v1/idps or api/v1/idps/{idpId} request that returns the client secret or API key. See Event types.

Updated translations

Translations of text on the Sign-In Widget have been updated.

Early Access

New skipping of entitlement sync during import of a user Systems Log event

The following System Log event has been added: Sync skipping of entitlement during import of a user.

Force rematching of imported users

This feature enforces a rematch for unconfirmed users imported from a profile source, whether through full or incremental imports. It attempts to match these imported users with existing Okta users. When this feature is enabled, every import re-evaluates matches for unconfirmed users.

Create dynamic resource sets with conditions

Resource set conditions help you limit the scope of a role by excluding an admin’s access to certain apps. This gives you more granular control over your custom admin roles and helps meet your org’s unique security needs. See Resource set conditions.

Granular account linking for certain Identity Providers

When admins link users from SAML and OIDC Identity Providers, they can now exclude specific users and admins. This improves security by allowing admins to configure granular access control scenarios.

Self-service toggle for Deactivate App Users

Admins can now use the self-service toggle to change what happens to an Okta user’s individual app assignments upon deactivation. If enabled, the user's individual app assignments deactivate instead of suspend. If a user is reactivated in Okta, the individual app assignments don't reactivate.

Restrict access to the Admin Console

By default, users and groups with assigned admin roles have access to the Admin Console app. With this feature, super admins can choose to manually assign the app to delegated admins instead. This is recommended for orgs with admins who don't need access, like business partners, third-party admins, or admins who only use the Okta API. See Configure administrator settings.

Fixes

  • When an admin clicked the Next button multiple times in succession while the table was loading, the number of Realm Assignments erroneously increased. (OKTA-725359)

  • Okta MFA for Active Directory Federation Services (ADFS) code wasn't signed. (OKTA-802958)

  • When using the Authenticator Method Chain feature with the Okta Admin Dashboard authentication policy, an error appeared if the chain didn't include the password authenticator. (OKTA-803569)

  • During self-service registration, the third-generation Sign-In Widget incorrectly validated some passwords that didn't meet the requirements. (OKTA-806543)

  • An authentication policy rule created with an authenticator instance couldn't be deactivated when the authenticator feature was disabled. (OKTA-806803)

  • When an API Service integration was assigned a custom admin role, it couldn't access certain OIDC apps. (OKTA-814731)

  • The MFA enforcement warning on the Admin Console Policy didn't appear in non-English locale settings. (OKTA-815246)

  • The description on the Entity Risk Policy page was incomplete for non-English locales. (OKTA-815370)

  • Some users couldn't sign in to Okta after an OIDC client was added to a new custom access policy. (OKTA-815668)

  • Some System Log events were displayed in Japanese instead of English. (OKTA-817904)

  • The Tasks dashboard widget had extra white space next to the Type column. (OKTA-818109)

  • Okta didn't check if generic and specific authenticator methods for the same authenticator were both present in a policy rule. (OKTA-818111)

  • The Sign-In Widget didn't correctly display warning text if the user entered an incorrect one-time passcode. (OKTA-819536)

  • The Application Usage report displayed an error message for Bookmark apps instead of usage data. (OKTA-819931)

  • Some users received an error message when they canceled the Sign in with Okta FastPass operation in the Sign-In Widget (second generation). (OKTA-820509)

  • Some users received an error message when they tried to delete the One factor access authentication policy if it contained mappings to deleted apps. (OKTA-822822)

  • System Log entries were created without information about changes made to Identity Provider discovery policy rules. (OKTA-824865)

  • An Authentication Method Chain rule was incorrectly flagged as not complying with the MFA requirements in the MFA Enforcement warning in the Admin Console. (OKTA-827219)

  • The Symantec Web Security Services app was timing out too quickly when doing a group push. (OKTA-829357)

  • Super admins who were assigned the role through a group couldn't view all support cases. (OKTA-831270)

  • An error occurred when admins attempted to deactivate some devices. (OKTA-835427)

  • Secure Partner Access app users were able to view and manage their own lifecycle actions. (OKTA-838254)

  • The Edit resource set page sometimes indicated that an unconditioned resource had conditions. (OKTA-838265)

  • The Create a resource set page was sometimes blank after an admin added an additional resource to a resource set. (OKTA-838266)

  • When the Authentication Method Chain was used, if a rule applied to registered and managed devices, the Are you trying to sign in? prompt didn't appear in the Okta Verify desktop app even though the Okta Verify FastPass authentication method required user interaction. (OKTA-838919)

  • Some text on the security methods page of the Sign-In Widget wasn't rendered correctly. (OKTA-839889)

  • The UI strings for the Secure Partner Portal app that were translated to Japanese were outdated. (OKTA-839956)

Okta Integration Network

  • Arxspan (SAML) has an updated ACS URL and Audience URI.
  • Avigilon Alta (SCIM) is now available. Learn more.
  • Brevity (SAML) is now available. Learn more.
  • Cisco User Management Connector (SCIM) has a new dynamic base URL.
  • DeepInfra (OIDC) is now available. Learn more.
  • Dext (OIDC) is now available. Learn more.
  • Kibana by Tech Prescient (SCIM) is now available. Learn more.
  • Smartsheet by Tech Prescient (SCIM) is now available. Learn more.
  • Speeda Customer Analytics (OIDC) is now available. Learn more.
  • XFA Discovery (API Service) is now available. Learn more.

Multiple Identifiers

Today, end users must sign in to Okta with a username or email address only. With the Multiple Identifiers feature, admins can configure identifiers, or user attributes from Universal Directory, that an end user can enter to authenticate. Multiple identifiers work in sign-on, recovery, self-service registration, and unlock flows. Admins can configure up to three identifiers, including email (which is still a required identifier). See Multiple identifiers.

Workday supports incremental imports

Workday now has the ability to run immediate, incremental imports. Incremental imports are much faster than full imports. However, they don't detect when users only have changes to custom attributes, so you must periodically run a full import to capture these changes. See Workday.

New flexible LDAP

A new LDAP schema allows flexibility by moving email to the custom schema and making first name, last name, username, and UID optional. This avoids error scenarios when an LDAP schema doesn't include specific attributes.

Prevent new single-factor access to the Admin Console

This feature prevents admins from configuring any new single-factor access to the Admin Console. This feature is now enabled by default for all orgs.

New browser tab reactivation behavior for the Sign-In Widget

The Sign-In Widget now avoids a full page refresh on custom domains when an inactive tab is reactivated. This change improves compatibility with browser memory saver features. This feature will be gradually made available to all orgs.

Sign in with duplicated email authenticators

Previously, users couldn't sign in if they had the same email enrolled twice as an authenticator. This change checks the status of each email authenticator and allows the user to sign in with the most suitable email authenticator.

End-user setting for nicknaming factors

End users can now nickname their phone, WebAuthn, and Okta Verify factors. If they have enrolled multiple instances of a factor, giving nicknames helps them identify the factors quickly (for example, "My personal cellphone" or "My office MacBook TouchID"). See the End-User documentation. This is a self-service feature.

Content security policy enforcement on end-user pages

Content Security Policy is now enforced for end-user pages in orgs with custom domains. Content Security Policy headers help detect attacks such as cross-site scripting and data injection by ensuring browsers know what kind of actions the webpage can execute. Future iterations of the Content Security Policy enforcement for end-user pages will become stricter than this first release. This feature will be gradually made available to all orgs.

Okta ThreatInsight coverage on core Okta API endpoints

Okta ThreatInsight coverage is now available for core Okta API endpoints (OpenID Connect & OAuth 2.0, Okta Management, and MyAccount API). Based on heuristics and machine learning models, Okta ThreatInsight maintains an evolving list of IP addresses that consistently show malicious activity across Okta's customer base. Requests from these bad IP addresses can be blocked or elevated for further analysis when Okta ThreatInsight is enabled for an Okta org.

Previously, Okta ThreatInsight coverage only applied to Okta authentication endpoints (including enrollment and recovery endpoints). With this release, enhanced attack patterns are detected for authentication endpoints and limited attack patterns are also detected for non-authentication endpoints.

There are no changes to the existing Okta ThreatInsight configuration. You can still enable Okta ThreatInsight with log and block mode, log mode, and exempt network zones. A new Negative IP Reputation reason is available for high security.threat.detected events. See System Log events for Okta ThreatInsight.

Application Entitlement Policy

Administrators can now override attribute mapping when assigning apps to individuals or groups. Attributes can also be reverted to their default mappings. See Override application attribute mapping. This feature will be gradually made available to all orgs.

Descriptive System Log events

When Okta identifies a security threat, the resulting security.threat.detected entry now provides a descriptive reason for the event. See System Log.

Improvements to the self-service registration experience

Earlier versions of the self-service registration (SSR) flow used a complicated array of templates to send activation emails to end users. The simplified SSR flow reduces this to only two email templates with customized welcome messages. If your application requires immediate verification of the end user's email address, Okta uses the Registration - Activation template. This template includes a magic link for a smoother sign-in experience. If email verification isn't immediately required to sign in to the application, Okta uses the Registration - Email Verification template. This template includes a link for end users to complete email verification at any time after they successfully sign in to the application. See Customize email notifications and the Okta email (magic link/OTP) integration guide.

SSO apps dashboard widget

The new SSO apps widget displays the number of user sign-in events across each of your org's apps over a selected period of time. You can use it to see which apps are used most frequently and to easily monitor the authentication activity across your org. See Monitor your apps.

Improvements to the self-service unlock process

Earlier versions of the self-service unlock (SSU) flow created unnecessary friction in the end user experience. The newly enhanced SSU feature introduces a seamless magic link experience in emails sent out to unlock accounts. Users no longer need to provide consent when using the same browser. In addition, after successfully unlocking their account, clicking the email magic link counts towards the application's assurance policy. After the assurance requirements are met, the user is signed directly in to the application. See Configure the email authenticator.

Toggle password visibility on the Okta Sign-In page

End users can now toggle visibility of their password on the Sign-In Widget, allowing them to check their password before they click Sign In. Note that passwords are visible for 30 seconds and then hidden automatically. See Authentication. See Enable delegated authentication for LDAP.

Email failure events in the System Log

Admins can now view email delivery failure events in the System Log. This helps admins better monitor the email event activity in their org. See System Log.

Choose additional filters for Office 365 sign-on policy

Filters have been added to enable admins to distinguish between web browsers and Modern Authentication clients when creating an app sign-on policy. See Office 365 sign-on rules options.

Device Authorization grant type

Advancements in internet technology have seen an explosion of smart devices and the Internet of Things. Consumers need to sign in to applications that run on these devices, but the devices either lack support for a web browser or have limited ability for input, such as smart TVs, car consoles, and thermostats. As a result, users resort to insecure authentication solutions that are error-prone and time-consuming.

The Device Authorization grant feature is an OAuth 2.0 grant type that allows users to sign in to input-constrained devices and also to devices that lack web browsers. This feature enables users to use a secondary device, such as a laptop or mobile phone, to complete sign-in to applications that run on such devices. See Configure Device Authorization.

Manage admin email notification subscriptions using API endpoints

Admins can manage email subscriptions using the Admin Email Subscription API endpoints.

  • Super admins can configure default subscription settings by admin type.

  • All admins can manage their own admin email notification subscriptions.

LDAP password reset option

LDAP delegated authentication settings can now be configured to allow users to reset their passwords. This change reduces the time needed for password management and allows users to reset their passwords quickly and easily. See Enable delegated authentication for LDAP.

LDAP admin password reset

For orgs integrated with LDAP, admins can now perform password resets for an active individual end user. See Reset a user password.