Okta Identity Engine release notes (Preview)
Version: 2024.08.0
August 2024
Generally Available
Sign-In Widget, version 7.21.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.
Detect and block requests from anonymizing proxies
Orgs can now detect and block web requests that come from anonymizers. This helps improve the overall security of your org. See Enhanced dynamic zones.
Okta LDAP Agent automatic update support
Admins can now initiate or schedule automatic updates to Okta LDAP agents from the Admin Console. With agent auto-update functionality, admins no longer need to manually uninstall and then reinstall Okta LDAP agents when a new agent version is released. Agent auto-updates keep your agents up to date and compliant with the Okta support policy, and help ensure your org has the latest Okta features and functionality. Single or multiple agents can be updated on demand, or updates can be scheduled to occur outside of business hours to reduce downtime and disruption to users. See Automatically update Okta LDAP agents.
Admin Console Japanese translation
When this feature is enabled, all admin users in the org who use Japanese as their display language will see the Admin Console in Japanese. See Supported display languages.
IP session restrictions for Okta Workflows
Okta super admins can now enable IP session restrictions for Okta Workflows. This feature ensures that all Workflows requests in a session use the same IP address that was logged when the session was created. If the IP address doesn't match any request, the session is terminated and the Workflows admin must sign in again.
Trusted App filters
Trusted App filters allow orgs to block applications from invoking Okta FastPass in Windows, and in Google Chrome and Firefox browsers for macOS. See Trusted app filters .
System Log event updates
In the System Log, the user.risk.detect event now appears instead of the user.risk.change event when Okta detects an entity that's associated with a risk level.
Continuous Access has been renamed to Post auth session. As a part of the change, the following System Log events have been renamed as well:
- policy.continuous_access.evaluate has been renamed to policy.auth_reevaluate.enforce
- policy.continuous_access.action has been renamed to policy.auth_reevaluate.action
Deprecating App Password Health report
The App Password Health report has been deprecated. Use the Sign On Mode filter in the User App Access report to view SWA application password reset dates. The capability to ask users to reset SWA passwords has been removed.
Deprecating Recent Unassignments report
The Recent Unassignments report has been deprecated.
- Use the System Log event application.user_membership.remove to identify users who have been unassigned from an application. See Recently unassigned users.
- Use the User App Access report to identify users currently assigned to applications. See User App Access report.
Updates to App Usage report
The Application Usage report has been updated.
- The maximum number of rows in a CSV is increased to five million.
- The date range field uses the user's local time zone when determining results.
- The report downloads automatically when possible.
Improved JIT performance for directory integrations
JIT-enabled directory integrations now have improved response times for JIT requests.
Require MFA for Admin Console access
You can require multifactor authentication to access the Okta Admin Console. When you enable this feature, all Admin Console authentication policy rules that allow single factor access are updated to require multifactor authentication. See Enable MFA for the Admin Console. This feature will be gradually made available to all orgs.
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.
System Log event updates
The following System Log events are now available:
- application.provision.group_push.deactivate_mapping
- system.agent.register
- security.attack_protection.settings.update
- device.platform.secret_key.reset
- system.self_service.configuration.update
- user.behavior.profile.reset
- security.events.transmitter.create
- security.events.transmitter.update
- security.events.transmitter.delete
- security.events.provider.create
- security.events.provider.update
- security.events.provider.activate
- security.events.provider.deactivate
- security.events.provider.delete
- system.identity_sources.bulk_upsert
- system.identity_sources.bulk_delete
- system.import.schedule
- system.import.user_match.confirm
- system.import.user_match.unignore
- system.import.user_match.update
- The application.lifecycle.update event now has the sessionIdleTimeoutMinutes and sessionMaxLifetimeMinutes fields. These fields add more session details to the event.
See Event types.
System Log event updates for Universal Directory
The following System Log events are now available:
- Linked object created
- Linked object deleted
- User profile updated
- Group owner updated
- Group owner removed
Identity Provider external names
Okta now warns admins if an Identity Provider (IdP) with custom attributes has an empty externalName field. Admins must now update the custom attribute through the API or delete it from the Admin Console and re-add it with the externalName field defined. This ensures that Okta receives the custom attribute when users enroll through Just-In Time provisioning scenarios.
Request throttling for jwks_uri
Okta has decreased the frequency at which it reloads JWKs from a customer's jwks_uri.
Rate limit for telephony inline hook
Okta now enforces by default a rate limit for the telephony inline hook to protect your org from toll-fraud attacks. See Connect to an external telephony service provider.
Universal Logout supported apps
The Surf browser now supports Universal Logout. This enables admins to automatically sign users out of this app when Universal Logout is triggered.
Authorization server default access policy deprecation
The authorization server default access policy is no longer provided in child orgs that are generated from APIs. Users can click Add New Access Policy to add policies. See Create access policies.
Early Access
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
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.
Require MFA for accessing Identity Governance admin apps
If your org uses Okta Identity Governance, you can require MFA for admins who access these first-party apps:
- Okta Access Certifications
- Okta Entitlement Management
- Okta Access Requests Admin
If you have auto-enabled Early Access features in your org, MFA is automatically enforced for those apps. See Enable MFA for the Admin Console.
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.
YubiKey preregistration
Customer admins were previously unable to enroll and ship YubiKeys as WebAuthn enrollments in a quick and automated way. The YubiKey preregistration feature enables admins to preregister YubiKey factors as WebAuthn enrollments for both staged and existing (active) users using a Workflows and Yubico integration to seamlessly handle the registration and shipment. See Require phishing-resistant authentication with pre-enrolled YubiKey.
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.
Biometric user verification in authentication policies
You can now configure authentication policies to require biometric user verification (no passcode). With this feature you ensure that users confirm their biometrics when they authenticate with Okta FastPass or Okta Verify Push. See Biometric user verification in authentication policies.
JIT provisioning for Smart Card
This feature enables you to provision Just-In-Time (JIT) access to users. You can do this by configuring certificate attribute criteria so that PIV/CAC card holders of other orgs can gain access to the resources they need. See Add a Smart Card Identity Provider.
Fixes
-
When the display language was set to Japanese, some text on the Upgrade Okta Verify with Push window wasn’t translated. (OKTA-658461)
-
Some Identity Providers didn't share custom attributes with Okta when the externalName field was empty. (OKTA-713526)
-
The Sign-In Widget didn't display the correct client ID when a customized client ID was used. (OKTA-722623)
-
Users with a custom admin role that included the View Directory permission were unable to view the Directory Integration page in the Admin Console. (OKTA-733030)
-
In some cases, an Okta org edition couldn't be changed. (OKTA-741688)
-
Admins couldn't edit IP restrictions for tokens created by agents. (OKTA-745048)
-
Some Android, iOS, and iPadOS users couldn't enroll with Okta Verify when the Higher security methods enrollment option was enabled. (OKTA-745318)
-
In some instances, a rate limit was reached when assigning entitlements to a user. (OKTA-746095)
-
The Universal Logout endpoint (oauth2/v1/global-token-revocation) used the incorrect OAuth 2.0 scope. (OKTA-747477)
-
Some users couldn't sign in if the global session policy that applied to them was deleted. (OKTA-754352)
-
System Log events weren't produced when admins changed an app's Radius Authentication Protocol settings. (OKTA-755604)
-
Admins received report emails with links to empty CSV exports. (OKTA-756393)
Okta Integration Network
- BRM (OIDC) is now available. Learn more.
- Getty Images (SAML) now has additional ACS endpoints.
- GitHub Enterprise Server is now called GitHub Enterprise Server (legacy).
- Haystack (SAML) is now available. Learn more.
- IBM AS/400 by Aquera (SCIM) is now available. Learn more.
- INCRMNTAL (OIDC) is now available. Learn more.
- Kuggar (OIDC) is now available. Learn more.
- Pmovel (OIDC) is now available. Learn more.
- Salesforce Social IdP was updated (OKTA-733640).
- UKG Ready by Aquera (SCIM) is now available. Learn more.
- Vinkey (OIDC) is now available. Learn more.
- WebWork Time Tracker (SCIM) is now available. Learn more.
- Wiz (API service) is now available. Learn more.
Weekly Updates
2024.08.1: Update 1 started deployment on August 14
Generally Available
Enforce MFA for Identity Governance admin apps update
The Enforce MFA for Identity Governance admin apps feature is available as a self-service Early Access feature only if the Enforce MFA to access the Admin Console feature is enabled.
Fixes
-
When admins viewed an OAuth client's secrets, Okta didn't trigger a System Log event. (OKTA-692600)
-
A System Log event wasn't always recorded when unlocked, Active Directory-sourced users tried to unlock their account from the Okta Sign-In Widget. (OKTA-724743)
-
The Identity Providers filter was missing from the Profile Editor page for some users in orgs that had the Enable Custom Admin Roles for Identity Providers feature turned on. (OKTA-724750)
-
Super admins who were assigned permissions through a group assignments couldn't see the Password Hash Export option even when it was enabled in the org. (OKTA-736079)
-
Some users couldn't sign in using a password and security question. (OKTA-740646)
-
Users to whom the Device Trust policy was applied received an error when signing in. (OKTA-745480)
-
The Allow Unknown Devices button wasn't visible on the user's profile page. (OKTA-746893)
-
Two Session timeout warning modals appeared when a user's session was about to expire. (OKTA-748766)
-
Admins couldn't search for AuthenticatorContext in the user.authentication.auth_via_mfa event in the System Log. (OKTA-750669)
-
The activation link in the Welcome email didn't always work. (OKTA-752981)
-
On the Roles, Resources, and Admins tabs on the Administrators page and in the Edit resources to a standard role dialog, admins couldn't use an ampersand (&) in their search. (OKTA-753904)
Okta Integration Network
- Anzenna has a new icon.
- Brainier LMS by Aquera (SCIM) is now available. Learn more.
- Cezanne (SCIM) is now available. Learn more.
- CloudAcademy has been rebranded as QA.
- DeleteMe (SCIM) now supports creating and updating users.
- dscout (SCIM) is now available. Learn more.
- Floqast has a new icon.
- IBM AS 400 by Aquera has been rebranded as IBM OS/400 on AS/400 (IBM i on Power Systems) by Aquera.
- Jellyfish (SCIM) has two new default user roles for the roles attribute.
2024.08.2: Update 2 started deployment on August 21
Fixes
-
When two or more OIDC Identity Providers (IdPs) were configured in an org, one of the IdPs' authorization codes could be processed by another IdP. (OKTA-672676)
-
The user icon description on the Sign-In Widget wasn't read by some assistive technologies. (OKTA-684423)
-
A blank warning message appeared when a report was blocked by a browser's pop-up blocker. (OKTA-692566)
-
The Test Delegated Authentication option ran the test flow designed for Classic Engine orgs. (OKTA-714631)
-
In orgs with the Okta account management policy configured for recovery, admins couldn't save the password policy without an authenticator selected. (OKTA-738910)
-
Japanese text wasn't wrapped properly on the Set up Okta Verify page of the Sign-In Widget. (OKTA-745200)
-
Some admins couldn't view the Edit profile and mappings button on the Edit IdP page when the identity provider custom admin role was enabled. (OKTA-747255)
-
App embed links that contained trailing slashes incorrectly redirected to the End-User Dashboard rather than the requested application. (OKTA-753261)
-
Some group admins couldn't use the CSV uploader. (OKTA-756654)
-
SSO IWA appeared on the Downloads page, which is unsupported for Identity Engine orgs. (OKTA-756656)
-
The policy.auth_reevaluate.fail System Log event didn't include a display message. (OKTA-790658)
-
When Authentication Method Reference (AMR) claims were sent as comma-separated values, AMR claims mapping for SAML failed. (OKTA-791512)
-
When the Authentication Method Chain feature was enabled, sometimes the Duo Security Authenticator couldn't be set as a step in the authentication chain. (OKTA-790533)
-
When the Authentication Method Chain feature was enabled with email and password as authenticators, SMS was incorrectly counted as a second factor. (OKTA-792089)
-
The link to the Session Violation Report on the Post auth session page didn't work correctly. (OKTA-793064)
Okta Integration Network
- Acsense (API service) is now available. Learn more.
- Backupta (OIDC) is now available. Learn more.
- Cisco User Management Connector Gov (SCIM) is now available. Learn more.
- Clutch Security (API service) now has the okta.oauthIntegrations.read scope.
- Figma (SCIM) is now available. Learn more.
- Greenhouse Onboarding by Aquera (SCIM) is now available. Learn more.
- myComply (OIDC) is now available. Learn more.
- Pendo (SAML) has a new integration guide.
- Reftab Discovery (API service) now has the okta.logs.read scope.
- Supernormal (SAML) is now available. Learn more.
- Syncly, Inc (OIDC) is now available. Learn more.
2024.08.3: Update 3 started deployment on August 28
Generally Available
Sign-In Widget, version 7.21.2
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.
Improved event reporting
The IP reputation data is now reported more frequently in System Log events. You can find this information in the DebugData or SecurityContext sections of the event.
Fixes
-
Admins couldn't create routing rules using the Policy API due to a cache issue. (OKTA-712397)
-
Group membership changes in Okta were sometimes incomplete in ServiceNow when Group Push was used. (OKTA-716692)
-
Policies with deny rules weren't considered duplicates and couldn't be merged. (OKTA-728707)
-
Some users that were running Apple macOS Ventura 13.6.7 couldn't authenticate. (OKTA-733975)
-
When the display language was set to Japanese, some text on the Create new resource set page wasn't translated. (OKTA-742653)
-
Okta didn't check whether operating system versions were greater than or equal to a required version. (OKTA-743658)
-
Provisioning of a user from a source to a target org failed in some Org2Org configurations because the user in the target org was still activating. (OKTA-747231)
-
When the Biometrics-only User Verification feature was disabled, activating or deactivating authentication policy rules with the biometrics-only constraint threw an error. (OKTA-755394)
-
When multiple PIV user identities were enabled, active identities with an expired password didn't show up as an option when a user signed in. (OKTA-791790)
-
The Sign-In Widget failed to prompt users with the last-used security method during the authentication flow. (OKTA-792783)
-
Some users couldn't sign in using a password and security question. (OKTA-793352)
-
When a user entered the wrong password to sign in to an org using delegated authentication to LDAP, the login cache was cleared.(OKTA-799642)
Okta Integration Network
- Adyen by Aquera (SCIM) is now available. Learn more.
- CloudAcademy (SAML) has a new logo, display name, support for additional endpoints.
- Command Zero (API service) now has additional scopes.
- Currents (SCIM) is now available. Learn more.
- DeleteMe now has SCIM functionality.
- Experience.com (OIDC) now has additional redirect URIs.
- TerraTrue (SCIM) now supports group push.
- Summize (SCIM) now has the openid scope.
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.
Okta Personal for Workforce
Okta Personal for Workforce is a set of features that allows admins to separate their users' work data from non-work data. Admins can now offer their end users a free Okta Personal account to store personal data, allow them to switch between accounts, and migrate personal apps from Okta enterprise tenant to Okta Personal. When Okta Personal for Workforce is enabled, personalized comms will be sent to the end users encouraging them to use Okta Personal for personal data and Okta enterprise for work data. See Okta Personal for Workforce User Experience.
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.