Okta Identity Engine release notes (Preview)

January
Preview org features

Version: 2025.01.0

January 2025

Generally Available

Sign-In Widget, version 7.27.1

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 Provisioning agent, version 2.2.0

This release contains bug fixes and minor improvements. The RPM installer is now signed. See Okta Provisioning agent and SDK version history.

Okta Active Directory agent, version 3.19.0

This release of the Okta Active Directory agent includes an additional layer of end-to-end encryption for payloads that are exchanged between Okta and the agent. Support for monitoring the Active Directory agent configuration file has been added, where a System Log event is emitted when the agent configuration has been changed on premises. This release also includes security enhancements and bug fixes. See Okta Active Directory agent version history

Granular configuration for Keep Me Signed In

Admins can now configure the post-authentication prompt for Keep Me Signed In (KMSI) at a granular level in authentication policies. This allows admins to selectively enable post-authentication KMSI on a per-user, per-group, or per-app basis. When enabled, this feature exposes a frequency setting that lets admins control how often the post-authentication prompt is presented to users. The post-authentication prompt text (title, subtitle, accept button, and reject button) is now customizable through the Brands management API. See Keep me signed in and Brands API.

OIN app for Microsoft Office GCC High

Office 365 app in GCC High environment is now generally available. This app is a highly secure version of Office 365 designed specifically for government entities, vendors, and contractors. See Configure Office 365 GCC High Tenant.

Block syncable passkeys

You can now block syncable passkeys during authentication. Previously, you could only block them during enrollment. This enhances the security of your org by preventing users from presenting such passkeys to attempt to enroll new, unmanaged devices. See Configure the FIDO2 (WebAuthn) authenticator.

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. This feature is now also supported in the Okta account management policy. See Authentication method chain.

Additional use case selection in the OIN Wizard

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

Automation
Centralized Logging
Directory and HR Sync
Multifactor Authentication (MFA)

See Use case selection in the OIN Wizard.

New group.source.id key for group functions in Expression Language

You can now use the group.source.id key in Expression Language group functions to filter between groups that have the same name.

Early Access

MFA for Secure Partner Access admin portal

MFA is required for accessing the partner admin portal app. See Manage Secure Partner Access.

Entitlement claims

You can now enrich tokens with app entitlements that produce deeper integrations. After you configure this feature for your app integration, use the Okta Expression Language in Identity Engine to add entitlements at runtime as OIDC claims and SAML assertions. See Generate federated claims.

Block syncable passkeys

Fixes

In some orgs, users were unlocked based on the settings of the default AD password policy rather than a higher priority password policy. (OKTA-755979)
The user counts weren't updated accurately when running Realm assignment jobs. (OKTA-790104)
Some text on the security methods page of the Sign-In Widget wasn't rendered correctly. (OKTA-803760)
Leaving the Custom character restriction field empty in the Profile Editor resulted in an error. (OKTA-811861)
The Manage Applications permission for Custom Admin roles unnecessarily allowed admins to mange the client credentials section for OAuth 2.0 Service apps. (OKTA-821119)
The MFA Enrollment by User report didn't include the security question authenticator in the list of authenticators in situations where it was enrolled in a Classic Engine org that was migrated to Identity Engine. (OKTA-823066)
In orgs using the Sign-In Widget (third generation), the Back to sign in link redirected users to the dashboard instead of the resource they intended to access. (OKTA-826892)
In orgs using the Sign-In Widget (third generation), self-service registration failed for users who provided an invalid attribute during their first registration attempt. (OKTA-834905)
Long group names were truncated on the Edit resources to a standard role page. (OKTA-839491)
Users who completed self-service registration saw unexpected behavior when they enrolled in authenticators from their Settings page. (OKTA-843223)
Viewing group members in the Admin Console sometimes displayed an error. (OKTA-844568)
In some orgs using the Okta account management policy, AD users received an error when they tried to edit their password. (OKTA-844675)

Weekly Updates

2025.01.1: Update 1 started deployment on January 15

Generally Available

Sign-In Widget, version 7.27.1

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.

Device assurance OS version update

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

Android 12, 13, 14, 15 security patch 2025-01-05
iOS 18.2
macOS Ventura 13.7.2
macOS Sonoma 14.7.2
macOS Sequoia 15.2
Windows 10 (10.0.17763.6659, 10.0.19044.5247, 10.0.19045.5247)
Windows 11 (10.0.22621.4602, 10.0.22631.4602, 10.0.26100.2605)

New IP service categories

The NORDLAYER_VPN and PIA_VPN proxy services are now supported as IP service categories in enhanced dynamic zones. See Supported IP service categories.

Fixes

The Slack start date wasn't imported through schema discovery. (OKTA-826971)
User movement logs for Realm assignment jobs didn't display correctly. (OKTA-844398)
When an Okta group was deleted while an app group reconciliation job was in progress, the job to delete the downstream app group wasn't scheduled. (OKTA-826938)
Users on some orgs encountered an HTTP 500 error response when they tried to authenticate. (OKTA-802900)
In orgs with Same-Device Enrollment for Okta FastPass enabled, some usernames with special characters were incorrectly displayed during Okta Verify enrollment on Android devices. (OKTA-839304)
By using device-to-device bootstrap, users could enroll in Okta Verify despite policy rules configured to block enrollment for these users. (OKTA-814436)

Okta Integration Network

Airflow by Tech Prescient (SCIM) is now available. Learn more.
Asana by Aquera (SCIM) is now available. Learn more.
Avigilon Alta (SCIM) now supports user deactivation.
Corma (API Service) is now available. Learn more.
Dovetail (OIDC) has a new icon and integration guide.
ELMO (SCIM) is now available. Learn more.
FCTR Identity Support Portal (SAML) is now available. Learn more.
Jotform (SAML) is now available. Learn more.
Island (SAML) has updated endpoints.
Natoma (SAML) is now available. Learn more.
Posit Workbench (SAML) is now available. Learn more.
Posit Workbench (OIDC) is now available. Learn more.
PrimeDrive (SAML) is now available. Learn more.
Rocketlane (SCIM) is now available. Learn more.
SAP HANA Provisioning Connector by Aquera (SCIM) is now available. Learn more.
Udemy Business (SCIM) is now available. Learn more.
UKG Pro Workforce Management by Aquera (SCIM) is now available. Learn more.
VASTOnline (SCIM) is now available. Learn more.
Vbrick Rev Cloud (SCIM) is now available. Learn more.

2025.01.2: Update 2 started deployment on January 29

Generally Available

Update to Access Certification reports availability

The Past Campaign Details and Past Campaign Summary reports are now available for campaigns that govern admin roles even if you're not subscribed to Okta Identity Governance.

Request expiration and enhanced notifications for Access Requests

To prevent accumulation of stale requests and improve the notification experience, Okta is making the following changes:

New requests now automatically expire after 60 consecutive days of inactivity. Completing a task, answering a question, or leaving a message on a request resets the 60-day expiration period. Any requests created before the general availability of this feature expire after 60 days of inactivity (on or around April 7, 2025).
Notifications about expiring requests are sent at 30 days, 5 days, and 1 day before the request expires.
The user setting to receive daily reminders about overdue tasks and requests is no longer available. It is replaced by the new request expiration notifications.

Sign-In Widget, version 7.27.3

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

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

Fixes

When a super admin updated a deactivated user to a different realm, admins received a Resource not found error. (OKTA-699778)
Searching a name with special characters in Realms failed. (OKTA-801220)
A permission wasn't checked for the MFA WebAuthn action. (OKTA-801809)
Some accounts that used custom admin roles were unable to create, delete, or unlink group push mappings. (OKTA-803378)
If an error occurred while an admin performed a protected action, the resulting error message was sometimes unclear. (OKTA-808668)
When a device name changed, the name displayed on the user profile page didn't match the the name shown on the Reset Authenticators page. (OKTA-811522)
Some users with the application administrator role weren't able to manage the apps they were assigned. (OKTA-814563)
The Manage Applications permission for custom admin roles unnecessarily allowed admins to manage the client credentials section of OAuth Service applications. (OKTA-821119)
The System Log sometimes displayed the org authorization server even though the error and the call were related to the custom authorization server. (OKTA-821988)
Users weren't signed out of Single Logout-enabled apps when they accessed Okta through a custom domain with iFrame embedding enabled. (OKTA-822650)
Users couldn't sign in to Okta after an app was deactivated and deleted. (OKTA-828955)
The Authentication Policy page sometimes displayed an error message instead of policies. (OKTA-832259)
Events for tokens revoked in bulk for a resource didn't appear in the System Log. (OKTA-834025)
Custom app instance icons weren't displayed in Profile Editor in the Admin Console. (OKTA-837626)
Some service account users received an error message despite successfully changing their passwords. (OKTA-841078)
Some admins received an error message when they clicked Admin on the End-User Dashboard. (OKTA-842573)
When admins updated an authentication policy rule, the previous and changed states didn't appear in the 'policy.rule.update' System Log event. (OKTA-843745)
The Atlassian Jira Cloud app didn't inject credentials when using SWA. (OKTA-843781)
Users received an error message when they enrolled a Personal Identity Verification card even though the System Log indicated that the enrollment was successful. (OKTA-846423)
Account unlock didn't work for some orgs using the Okta account management policy. (OKTA-848066)
The Username hint was inaccurate. (OKTA-851440)
Some users could enroll authenticators with self-attested passkeys even though the admin only allowed certificate-based attestation in their org. (OKTA-851468)
On the Admin Dashboard, the Tasks widget sometimes didn't load. (OKTA-851807)
When admins tried to customize the signing options of the SAML 1.1 app, their changes didn't appear. (OKTA-852911)
In orgs with Multiple Identifiers enabled, some users couldn't perform self-service registration. (OKTA-853911)
The Administrator assignment by role page displayed an error if an admin had duplicate assignments. (OKTA-854906)
The email notification for protected actions indicated that actions were taken instead of attempted. (OKTA-854973)
Users with passwords greater than 16 characters couldn't sign in when the Password Authentication Protocol with Message-Authenticator feature was enabled. (OKTA-856260)

Okta Integration Network

ADP Link by Aquera (SCIM) is now available. Learn more.
Cirro (OIDC) is now available. Learn more.
Concentric AI (SAML) is now available. Learn more.
Cyble Vision (SAML) is now available. Learn more.
Dayforce by Aquera (SCIM) is now available. Learn more.
Deel HR (SCIM) now supports profile sourcing.
FCTR Identity Support Portal (API Service) is now available. Learn more.
Gumband (OIDC) is now available. Learn more.
Island Management Console (SAML) has updated endpoints.
Microsoft SQL Server by Aquera (SCIM) is now available. Learn more.
Opensense (SAML) is now available. Learn more.
QuickBooks Online by Aquera (SCIM) is now available. Learn more.
Payflows (SAML) is now available. Learn more.
Redshift by Aquera (SCIM) is now available. Learn more.
Resonance by spiderSilk (SAML) is now available. Learn more.
SmartSite (OIDC) is now available. Learn more.
Speeda Sales Insights (OIDC) is now available. Learn more.
TrustWorks (SAML) is now available. Learn more.
XplicitTrust Network Access (API Service) is now available. Learn more.

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.

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.

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.

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.