Okta MFA Credential Provider for Windows, version 1.3.8

This version of the agent contains bug fixes and security enhancements. See Okta MFA Credential Provider for Windows Version History.

Identity Governance

Okta Identity Governance is a SaaS-delivered, converged, and intuitive Identity and Access management platform. Use it to simplify and manage your identity and access lifecycles across multiple systems and improve the overall security of your company.

Use Okta Identity Governance solutions, such as Access Certifications, Access Requests, and Reports to:

• Efficiently create, protect, and audit access to critical resources.

• Improve your company’s security. Increase employee productivity.

• Improve IT efficiency by automating tasks to reduce the time taken and errors associated with manual data entry and provisioning tasks.

See Identity Governance.

Note that Okta Identity Governance is available to customers on a subscription basis. For more information, contact your Account Executive or Customer Success Manager.

Preview the token inline hook

Before implementing a token inline hook, you can now preview the hook request and the external-service response in the Admin Console. This feature aids in the development and testing of inline hooks before releasing to a production environment. See Preview an inline hook and Preview and test the token inline hook.

IE and Edge Legacy plugins

You can no longer download the Internet Explorer (IE) and Edge Legacy browser plugins from the Downloads page. These plugins aren't supported.

Improvements to the sign-in experience

When users create an account using the Sign Up link in the Sign-In Widget, they enter their first and family names along with their email address on the first page. The Sign-In Widget then displays the authenticators page, where users enter a password and configure any other mandatory authenticators. To streamline the sign-up process, the Self-Service Registration with Password feature allows you to show the password entry on the first page of the enrollment form instead. See Collect profile information and register users.

Manage embedded widget sign-in support

Okta provides the Okta Sign-In Widget out of the box so that customers can authenticate users by simply redirecting them to the widget. For customers who need a customized sign-in experience, Okta also provides a widget SDK that developers can embed within their applications. This embedded widget uses a custom authorization mode called the Interaction Code grant type to authenticate users. The Embedded widget sign-in support toggle allows super admins to disable the embedded sign-in option across all applications and authorization servers. This helps to create consistency and improves the security posture of your applications. See Configure embedded sign-in support.

Security enhancement of Okta Verify push notifications

To help users recognize and prevent phishing attacks, Okta Verify push notifications on mobile devices and Apple Watch include the name of the app to be accessed and the org URL.

ChromeOS as a device platform

You can now select ChromeOS as a device platform in authentication policy rules or identity provider routing rules. This enables you to configure how users access Okta-protected resources from ChromeOS devices. See Add an authentication policy rule and Configure identity provider routing rules

Authentication policy rules:

Identity provider routing rules:

Certificate chain builder for Smart Card IdP

Admins can now upload individual certificate files to build a certificate chain for a Smart Card IdP. This eliminates the requirement to manually create a file that contains the certificate chain. See Add a Smart Card Identity Provider.

Telephony usage report

The Telephony usage report displays data about an org’s telephony events over time. The report can be filtered by voice or SMS events and helps admins quickly understand usage trends and troubleshoot deliverability or request issues. See Telephony usage report.

Email deliverability events in the System Log

Admins can now view the following email deliverability event types in the System Log:

• Delivered
• Deferred
• Dropped
• Bounce

This helps admins better monitor the email deliverability activity in their org. See System Log.

Single sign-out changes for custom domains

If an admin signs out from a custom domain, their Admin domain and subdomain sessions now remain active. If they sign out from the Admin domain or subdomain, their custom domain session is ended.

People page improvements

People page filter results are improved as follows:

• Status > Password reset filter results now include users with both Password expired and Password reset status.

• Status > Active filter results return only users with an active status.

OKTA-508888

Some orgs were unable to configure their global session policies to display the password-first Sign-In Widget.

OKTA-509453

Staged and provisioned user accounts received different error messages when they clicked Forgot password? on the Sign-In Widget. This occurred in orgs with User Enumeration Prevention turned on.

OKTA-527215

Routing rules incorrectly redirected some users to an IdP before they could enter their username.

OKTA-532720

Some YubiKeys didn't work for authentication even though they were successfully enrolled.

OKTA-534595

Admins with a custom role couldn't edit the users in a group if the group was assigned to an app with profile sourcing enabled.

OKTA-536037

When a DELETE request to the /api/v1/authorizationServers/<authServerID>/clients/<clientID>/tokens endpoint was called for large scale operations, an HTTP 500 error was returned.

OKTA-538402

Some admins weren't able to delete network zones after they upgraded to Identity Engine.

OKTA-541442

Errors during federation sometimes didn't display the cause of the error.

OKTA-542472

The authn_request_id information was missing from the user.authentication.auth_via_mfa System Log event for Okta Verify Push verifications.

OKTA-544783

The Norwegian translation of the end-user settings and preferences menu was incorrect.

OKTA-546310

Admin roles that were constrained to a group with group rules couldn't be assigned to a user or group.

OKTA-547525

The Welcome page, SMS reminder prompt, and security image prompt weren't displayed for users accessing Okta using AD SSO in incognito mode.

OKTA-549174

After upgrading to Identity Engine, orgs with custom domains couldn't use getRequestContext in the Sign-in page code editor.

OKTA-549537

The Box integration provisioning menu didn't display the correct settings.

OKTA-549886

Using an Agentless DSSO test endpoint without any routing rules configured to use ADSSO resulted in a 404 error.

OKTA-550773

Some orgs didn't correctly recognize a sign-in attempt using a smart card.

OKTA-550789

Provisioning new users from Okta to Office 365 failed.

OKTA-551130

The Email Authenticator challenge lifetime was sometimes set to five minutes regardless of its value in the authenticator settings.

OKTA-552637

Users were sometimes signed out of Okta right after signing in if the tokens returned were too large.

OKTA-552810

Customized sign-in pages for orgs using a custom domain didn't render properly.

OKTA-553284

When the full-featured code editor was enabled, updates to email customizations, custom error pages, and the sign-in page didn't trigger System Log events.

OKTA-557858

Internet Explorer 11 users were blocked from signing in to orgs that used custom domains.

App Integration Fixes

The following SWA apps were not working correctly and are now fixed:

• Chase (OKTA-549904)

• iAuditor (OKTA-549658)

• MeridianLink Consumer (OKTA-541626)

• Office 365 Dynamics (OKTA-549978)

• Quickbooks (OKTA-549905)

Okta AD Agent, version 3.13.0

This version of the agent contains the following changes:

• Health check of auto update service before auto update process is started
• Web proxy support for agent auto update feature
• Updated log category for existing logs from DEBUG to INFO
• Security fixes

See Okta Active Directory agent version history.

Okta RADIUS Server agent, version 2.17.7

This version of the agent contains security fixes and resolves a memory leak that occurred when agents were configured for EAP-TTLS. See Okta RADIUS Server Agent Version History.

Improvements to the self-service password reset experience

Previously, the self-service password reset (SSPR) flow created unnecessary friction in the user experience. The newly enhanced SSPR feature introduces a seamless magic link experience for password reset emails. Users no longer need to provide consent when using the same browser. After a successful password reset where the password meets the application’s assurance policy, the user is signed directly to the app. See Configure the Email authenticator. This feature is currently enabled by default for new orgs only.

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. This feature is currently enabled by default for new orgs only.

New permissions for custom admin roles

Super admins can now assign these new permissions to their custom admin roles:

• Manage authorization server
• View authorization server
• Manage customizations
• View customizations

The authorization server permissions can be scoped to all or to a subset of the org’s authorization servers. With these new permissions, super admins can now create custom admin roles with more granular permissions for managing their org’s customizations and authorization servers. See About role permissions.

New HealthInsight tasks

Two new HealthInsight tasks help admins improve the security of their global session policies. HealthInsight now provides guidance for increasing the required authentication frequency for specific resources, and for requiring high-risk users to provide MFA every time they sign in. See Change the authentication frequency and Evaluate a risk score for each request.

Event hooks for consent revocation

Consent revocation events are now selectable for use with event hooks. See Create an event hook . See Event Types for a list of events that can be used with event hooks.

Agentless Desktop Single Sign-on

With Agentless Desktop Single Sign-on (DSSO), you don't need to deploy IWA agents in your Active Directory domains to implement DSSO functionality. This reduces or eliminates the maintenance overhead and provides high availability as Okta assumes responsibility for Kerberos validation. See Active Directory Desktop Single Sign-on.

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

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

Agentless Desktop Single Sign-on authentication progress updates

Agentless Desktop Single Sign-on (ADSSO) authentication progress pages have been updated to make authorization and verification progress more visible and improve the user experience. See Configure agentless Desktop Single Sign-on.

Password expiration settings for Active Directory

You can specify the password expiration policies for Active Directory for all preview organizations to set the maximum password age in days and the number of days before password expiration when the user receives a warning.

JIT users from Active Directory

Just-In-Time (JIT) provisioning enables automatic user account creation in Okta the first time a user authenticates with Active Directory (AD) delegated authentication, Lightweight Directory Access Protocol (LDAP) delegated authentication, or Desktop SSO. JIT account creation and activation only works for users who aren't already Okta users. This means that users who are confirmed on the import results page, regardless of whether or not they were subsequently activated, aren't eligible for JIT activation. When JIT is enabled, users don't receive activation emails. See Add and update users with Active Directory Just-In-Time provisioning and Add and update users with LDAP Just-In-Time provisioning.

Service Principal Name functionality improvement

New Service Principal Name (SPN) functionality allows Agentless Desktop Single Sign-on (ADSSO) authentication to continue without interruption when an SPN is updated. A service account and an SPN are required for ADSSO Kerberos authentication. With this change, you can now update the SPN frequently as an additional security precaution. See Create a service account and configure a Service Principal Name.

Enhanced Okta LDAP integrations with Universal Directory

Okta LDAP integrations now feature custom mapping, schema discovery, and a fully extensible attribute schema that allows you to import or update any attribute stored in LDAP. With these enhancements, Okta LDAP matches the schema functionality already available to Active Directory integrations. See Profile Editor.

OpenLDAP support for Auxiliary Object classes

You can now input a comma-separated list of auxiliary object classes when importing users from LDAP. See Configuring Your LDAP Settings.

New rate limits dashboard filter

You can now filter the APIs listed on the rate limits dashboard by their rate limit multiplier eligibility status. See Rate limit monitoring.

Eligible authenticators in Security Methods list

The Security Methods list on the Settings page now displays only those authenticators that a user may enroll in as determined by the configuration of the org's authenticator enrollment policy. This improves the user experience by ensuring that users are only presented with options that lead to successful authenticator enrollment.

ISV Portal email address updated

The email address for ISV Portal communications is now oanapp@okta.com.

Invalid phone numbers rejected

Okta now rejects attempts to enroll a toll-free, premium, fixed-line (SMS), or any other invalid or unrecognized phone number. This ensures that only valid phone numbers are used for multifactor authentication or device enrollment. See Configure and use telephony.

Enhancement to System Log event

The USER_AUTHENTICATION_AUTH_VIA_MFA System Log event has been enhanced. It now records the URL and IP address of a suspicious website and the mismatched origin header from the HTTP request when Okta detects and blocks a phishing attempt. This enhancement enables admins to track patterns of suspicious activity.

OKTA-476449

Admins could create resource sets that contained duplicate resources.

OKTA-512927

Two different Okta users could be linked to the same AD user through provisioning.

OKTA-515733

Users were sometimes signed out of Okta right after signing in if the tokens returned were too large.

OKTA-523330

Okta Provisioning Agent (x64 RPM) and Okta Provisioning Agent (Windows x64) were incorrectly swapped.

OKTA-526726

When admins deleted a property in an implicit app user schema, a property with the same name couldn't be recreated after the deletion.

OKTA-529966

Users couldn't enroll a Voice Call Authentication (MFA) factor if Twilio was used as the provider and the phone number had a comma in its extension.

OKTA-530843

Parallel JIT requests for the same username created duplicate users.

OKTA-532898

A long text string was displayed outside of the General Settings page in OIN Manager.

OKTA-532900

The Enter your Post Logout Redirect URI field for OIDC settings in OIN Manager didn't accept all valid URLs.

OKTA-533309

When signing in to a RADIUS app, users were sometimes shown the incorrect operating system in Okta Verify push messages.

OKTA-533753

Admins couldn't add more than 10 translations of a customized email template.

OKTA-533897

Google background service users received unrequested Okta Verify Push notifications.

OKTA-544628

Some orgs experienced internal server errors during outbound SAML federation.

Okta LDAP agent, version 5.15.0

This version of the agent contains Security enhancements. See Okta LDAP Agent version history.

Okta RADIUS Server agent, version 2.17.6

This version of the agent contains security fixes. See Okta RADIUS Server Agent Version History.

Okta On-Prem MFA agent, version 1.6.0

This version of the agent contains security fixes. See Okta On-Prem MFA Agent Version History.

Lockout Prevention

This feature adds the ability to block suspicious sign-in attempts from unknown devices. Users who sign in to Okta with devices they’ve used before won’t be locked out. See Configure a password policy.

Non-deletable default authorization server

The default authorization server is a custom authorization server provided by Okta so that customers can quickly get started working with Okta. However, if a customer deletes the default authorization server, it can't be restored, causing confusion and disruption. This enhancement prevents you from deleting the default authorization server, although you can disable it if isn’t required. To aid in identification, Okta adds a Default label for the default authorization server in the Admin Console. See API access management.

ODSEE LDAP support

Okta now supports Oracle Directory Server Enterprise Edition (ODSEE) LDAP integrations with the upgrade to LDAP agent version 5.6.3 and later. See Oracle Directory Server Enterprise Edition LDAP integration reference.

eDirectory LDAP support

Okta now supports eDirectory LDAP integrations with the upgrade to the LDAP agent version 5.6.2 or later. See eDirectory LDAP integration reference.

Custom error message

Admins can now customize the error message that users receive when their access is denied. This allows admins to provide remediation steps and/or point users to documentation that helps resolve their access issues. See Customize the access denied error message.

Clone authentication policies

Creating an authentication policy from scratch is a manual, error-prone task because you need to visually copy existing rules into the new policy. Okta now offers the ability to clone a policy. You can use either the Admin Console or the new Clone a Policy operation on the Policy API. See Clone an authentication policy.

Dynamic routing rules

Org admins can now consolidate multiple IdP routing rules into a single dynamic routing rule. Dynamic routing rules use expression language to match users to any IdP, based on attributes of their login object. This reduces the volume and complexity of routing rules and the manual effort of managing them. See Configure dynamic routing rules.

App conditions in authentication policies

Admins can now apply an authentication enrollment policy rule to specific applications, to any application that supports MFA enrollment, or to Okta. This enables admins to configure their policies with more granularity, bringing even greater security and flexibility. This release brings this feature into parity with the functionality available in Classic Engine. See Configure an authenticator enrollment policy rule.

On-Prem MFA agent security provider

The On-Prem MFA agent now uses a FIPS-compliant security provider.

Generate private key in PEM format

You can now use either the PEM or JWK format for the private key when generating a public/private key pair from the Admin Console. The public key doesn't support PEM.

Enhanced SMS and Voice blocking

Additional measures are now applied to block suspicious SMS and Voice traffic from countries that are typically at risk of toll fraud attacks. Blocked transactions display a deny status in the System Log.

Email notifications for agent connection issues

Customers are now notified by email in cases of mass agent disconnect/reconnect issues.

Username match criteria

A new Organization Security setting determines how a user’s profile is matched when they sign in. Allow short match lets users sign in without their domain, while Match entire username requires the domain. See General Security.

OIN Manager enhancements

The OIN Manager landing page now includes a set of support links and a search bar to aid in integration submissions.

Improvements to API authorization server interface

Administrators working with OIDC client applications can now see a preview of the information contained in the refresh token and the device secret returned by the authorization server. See Build Custom Authorization Servers for API Access Management.

IdP logos added

Logos have been added to the existing IdPs.

OKTA-429940

Users were able to make unlimited attempts to activate their One-Time Password (OTP) based factors (such as SMS, CALL, EMAIL, Google OTP, and Okta Verify TOTP).

OKTA-516459

The RSA SecurId agent didn't use proxy settings during installation.

OKTA-518378

ADSSO functionality didn't working for UD, MFA, adaptive MFA, lifecycle management, and mobility management workforce.

OKTA-523494

AD-sourced users were able to sign in to Okta even when they moved out of a searchable OU.

OKTA-530753

The Help link on the Features page was incorrect.

OKTA-531308

An error message didn't appear when a deleted app instance was assigned to a role.

OKTA-532316

When a session.amr expression was used for SAML attribute statements, the attribute statement wasn't correctly populated.

OKTA-536457

AD-sourced users who reset their passwords in AD had to reset their passwords again when using IWA or ADSSO to sign in to Okta.

OKTA-537036

An inaccurate message appeared on the HealthInsights page when more rules were available to view.

App Integration Fixes

The following SWA apps weren't working correctly and are now fixed:

• AdvancedMD (OKTA-534085)

• Constellation Energy Manager (OKTA-532146)

• HireRight (OKTA-536400)

• MyFonts (OKTA-536268)

• VitalSource Bookshelf (OKTA-529478)

OIDC for the following Okta Verified applications:

• Corrata: For configuration information, see Corrata Okta Integration Guide.

• Entrustient: For configuration information, see Okta Configuration Guide.

• Foreman: For configuration information, see Foreman - Okta SSO Guide.

• Rybbon: For configuration information, see Rybbon Configuration Guide (you'll need credentials to access this documentation).

Okta ADFS plugin, version 1.7.11

This version of the plugin contains bug fixes, security enhancements, and support for an additional top-level domain. See Okta ADFS Plugin version history.

Okta MFA Credential Provider for Windows, version 1.3.7

This version of the agent contains fixes, security enhancements, and support for an additional top-level domain. See Okta MFA Credential Provider for Windows Version History.

PKCE validation for OIDC app integrations

You can now require Proof Key for Code Exchange (PKCE) as an additional verification step for any OIDC app integration except service apps. The OAuth Security Best Current Practice recommendation is to use PKCE for all uses of the authorization code flow, regardless of the client type. See Create OIDC app integrations.

Validation and verification of signed SAML requests

Using signed SAML requests ensures that incoming requests are from genuine applications. When this is configured, Okta only accepts SAML requests signed using the certificate associated with the app integration. Having signed SAML requests also resolves scenarios where the Assertion Consumer Service (ACS) URL requested after authentication can be one of several domains or URLs. When a Service Provider sends a signed authentication request, Okta can accept dynamic ACS values as part of the SAML request and posts the SAML assertion response to the ACS value specified in the request. See the Advanced Settings section of Create SAML app integrations.

Shared SWA app accounts, password restriction

For SWA apps with an account sign in option set to Users share a single username and password set by administrator, only Super admins or App admins with permissions for that app can view the password.

Device assurance for unmanaged devices

While you can secure access to your corporate resources with passwordless MFA using Okta FastPass, you can’t ensure the security posture of the device itself before granting access. This is especially true for unmanaged devices, where a complementary device management agent isn’t present to validate the compliance status of that device. Device Assurance policies enable you to define device security posture requirements that must be satisfied in order for a user to access a protected resource. This allows you to protect your organization's data and services by ensuring access is only granted to secure devices, even if those devices aren’t managed. See Device assurance.

LDAP real-time synchronization

With real-time synchronization, user profiles, groups, and group memberships can now be updated when LDAP-sourced users sign in to Okta, or when they refresh their People page. Admins no longer need to perform full or incremental imports of user attributes, and user profiles, groups, and group memberships are always up to date. Real-time synchronization also reduces the burden on system resources because user attributes are imported and updated individually and not in large groups. See Manage your LDAP integration.

New Recent Activity page on the new Okta end-user dashboard

The Recent Activity page provides end users with a summary of recent sign-in and security events for their Okta account. End users can also report suspicious activity to their Okta admin by clicking I don’t recognize this. See Recent Activity.

Custom domain status

On Customizations > Domain, a new Status field indicates whether the Custom URL Domain configuration is active, pending, or certificate expired. See Customize the Okta URL Domain.

Clarified sign in widget text

The instructions on the Verify with your email page of the Sign-In Widget now specify that the end user must click the action button for Okta to generate and send the verification email.

OIN Manager user interface changes

The OIN Manager includes the following updates:

• The UI has been updated to match the current Okta style.
• The Okta logo has been updated.
• A note that lists the time required to process new submissions is displayed.

403 error for rate limit violations

When an org reaches its operational rate limit for SMS requests, a 403 Forbidden error is now displayed instead of a 429 Too many requests error. See Configure client-based rate limiting

OKTA-482997

The Custom Authenticator sent push notifications even when the Send push automatically checkbox wasn't selected.

OKTA-496347

The password field in the Add Person widget was incorrectly truncated.

OKTA-499408

The help link for Automatically update Okta Active Directory (AD) agents on the Early Access page pointed to an outdated help topic.

OKTA-506480

AD agent emails incorrectly indicated that agents already running the latest version had recently been auto-updated.

OKTA-515159

When an admin customized an email template not used for sign-in flows, the app.id, app.name, and app.label variables didn't resolve correctly.

OKTA-518347

Some Org2Org users had the same ExternalID on the target org.

OKTA-522912

The text in the Sign-In Widget implied that the verification code was sent in a email but Okta hadn't generated that email yet.

OKTA-523033

Inline enrollment of additional authenticators asked users to enroll authenticators based on global session policy settings.

OKTA-523140

When Salesforce provisioning was configured using OAuth, Salesforce Community Profiles weren't displayed.

OKTA-523607

Users could sign in with ADSSO after delegated authentication was disabled.

OKTA-524632

Searching for users on the Assign People page returned an Invalid Search Criteria error if the secondary email was marked as a sensitive attribute.

OKTA-529018

The catch-all rule in the default authentication policy required password only.

App Integration Fixes

The following SAML app was not working correctly and is now fixed:

• Salesforce (OKTA-516730)

Customize Okta to use the telecommunications provider of your choice

While Okta provides out of the box telephony functionality, many customers need the ability to integrate their existing telecommunications provider with Okta to deliver SMS and Voice messages.

The Telephony Inline Hook allows customers to generate one-time passcodes within Okta and then use their existing telecommunications provider to deliver the messages for MFA enrollment/verification, password reset, and account unlock using SMS or Voice. This allows customers to use their existing telephony solution within Okta, due to the time they've already invested in their existing telephony solution, the need to use a specific regional provider, or simply the desire to maintain flexibility. See Customize your telephony service provider.

Configurable API token rate limits

Admins can now configure a percentage rate-limit capacity for individual API tokens. Previously, when a token rate limit violation occurred, it wasn’t clear which token consumed the limit. Setting a maximum capacity for each token solves this problem and gives admins a new tool to investigate rate-limit violations and plan for future deployments. See API token management.

Salesforce REST OAuth

Admins can now upgrade to the latest version of our Salesforce integration. OAuth authentication will be now used for Provisioning and Imports. See Configure OAuth and REST integration. This feature is now enabled by default for all orgs.

Merge tool for duplicate authentication policies

Admins can simplify policy management by merging duplicate authentication policies. The merge tool finds authentication policies with the same rules, moves their apps to a single policy, and then deletes the duplicates. After the automated process runs, admins can then make edits and app assignments in a single policy. See Merge duplicate policies.

Custom Administrator Roles

The standard admin roles available today don’t always meet all the granular delegated administration requirements, which may result in admins having either more or less permissions than they need.

The Custom Administrator Roles feature allows super admins to:

• Create admin assignments with granular roles, which include specific user, group, and application permissions.

• Constrain these admin assignments to resource sets.

Use Custom Administrators Roles to:

• Increase admin productivity.

• Decentralize the span of access that any one admin has.

• Grant autonomy to different business units for self-management.

Some important things to note:

• The Administrators page has been updated with a new, more intuitive interface for managing roles and permissions. See About the Administrators page.

• Your pre-existing roles are referred to as “standard roles”. The standard role functionality is the same as earlier but the UI is different. See Use standard roles.

• You can continue using the pre-existing roles and your existing assignments remain the same.

• You can also assign custom roles to users who have standard roles assigned.

See Custom admin roles and Best practices for creating a custom role assignment.

Bulk assign users to groups

Admins can now use bulk import functionality to assign multiple users to specific Okta groups. Bulk user import significantly reduces the time admins spend managing user group assignments. In addition, this functionality makes it easier for large enterprise orgs to adopt Okta as their access management provider. See Bulk assign people to a group. This feature will be gradually made available to all orgs.

Okta Admin Console Groups page enhancements

The Okta Admin Console Groups page has been updated to simplify the addition of large numbers of users to groups and reduce the likelihood that all users can be accidentally removed from a group. In addition, search functionality has been significantly improved to make adding and removing users from groups quicker and easier. See Manage groups. This feature will be gradually made available to all orgs.

Advanced search for users and groups

To make it easier for admins to quickly locate and manage users and groups, enhanced people and group search functionality is now available. Admins can limit search results to specific criteria using the SCIM protocol to query. They can also use Created On and Last Updated On in their queries to identify when users or groups were created or last modified, and search for groups and users using both base and custom attributes. These advanced search options optimize search results and help reduce the time spent searching for specific information. See View group members. This feature will be gradually made available to all orgs.

Trusted Origins for iFrame embedding

You can now choose which origins can embed Okta sign-in pages and the Okta End-User Dashboard using Trusted Origins for iFrame embedding. This feature offers a granular control over iFrame embedding compared to the existing embedding option in Customization, which doesn't let you distinguish between secure and non-secure origins. Trusted Origins under Security > API allows you to selectively configure the origins you trust. It also provides enhanced security as it uses a more secure frame-ancestors directive in Content Security Policy that protects your data from web attacks such as clickjacking. You can also migrate your existing iFrames to Trusted Origins. See Trusted Origins for iFrame embedding.

Okta AD agent, version 3.12.0

This version of the agent contains the following changes:

• Improved group membership information logging

• Security enhancements

See Okta Active Directory agent version history.

Okta RADIUS Server agent, version 2.17.5

This version of the agent contains security fixes and resolves a memory leak that occurred when agents were configured for EAP-TTLS. See Okta RADIUS Server Agent Version History.

Okta On-Prem MFA agent, version 1.5.1

This version of the agent contains security fixes. See Okta Okta On-Prem MFA Agent Version History.

Event hooks for log streaming

To provide better visibility into changes in the state of Okta log streams, event logs pertaining to log stream management, such as stream deactivation, are now eligible for event hooks. Event hooks allow you to automate detection and responses to changes in the state of a log stream. See Log streaming.

Rate Limits dashboard includes API Token data

The Rate Limits dashboard now includes API Token data on the Rate limit usage over time graph. You can view bar graph data from API tokens or by IP address to review any spike in traffic. See bar graph and API rate limits by token.

System Log events for Report CSV actions

For enhanced security and auditing, the System Log now records new events when CSVs of reports are requested, generated, and downloaded.

System Log update for authentication policy

Authentication policy update events include a new DebugData field with details about how the rule was changed.

System Log update for telephony operations

The system.operation.rate_limit.violation event is no longer fired when SMS or Voice messages are blocked due to telephony operational rate limit violations. Instead, telephony system.sms.send.* and system.voice.send.* events are issued as a DENY System Log message.

Microsoft Azure Join documentation

Help documentation is now available for users integrating Azure Join and Okta. See Typical workflow for integrating Hybrid Azure AD Join.

AD Agent auto-updates only when operational

The AD agent auto-update scheduler no longer automatically updates non-operational agents. See Schedule agent auto-updates.

The YubiKey authenticator renamed

The YubiKey authenticator is renamed YubiKey OTP. See Configure the YubiKey OTP authenticator.

OIN Manager enhancements

The contents of the automated email sent when an integration has been moved to Draft after a period of inactivity have been updated.

OKTA-454135

The pending user action status was unclear on the new group membership page.

OKTA-466964

The Edit icons on the Application > Provisioning tab were visible to admins who didn't have the Manage applications permission.

OKTA-492931

Admins couldn't edit the MFA requirement and session expiration settings in the default rule of a global session policy.

OKTA-494505

Okta Expression Language worked incorrectly in app pages after the page was saved and reloaded.

OKTA-505852

AD agents running versions prior to 3.8.0 were displayed in existing auto-update schedules.

OKTA-508762

Workday incremental imports with a pre-hire level set prematurely picked up some updates from within the pre-hire interval.

OKTA-509105

Upgrading to Identity Engine resulted in AWS Redshift connectivity issues.

OKTA-509671

When a custom admin role was deleted, users with no other assigned admin roles could still see the Admin button on the Okta End-User Dashboard.

OKTA-511909

When admins applied the Not managed filter on the Devices inventory page, some unmanaged devices were missing from the list.

OKTA-511933

LDAP agents failed to parse queries when group names had special characters.

OKTA-512433

On the Admin Dashboard, the Items count for the Applications can be updated to use SAML task wasn't correct.

OKTA-515783

Sometimes, in the Groups page Description column, an equals sign (=) replaced the forward slash ( / ) in LDAP-sourced group names.

OKTA-518090

The Authentication Policies page didn't load if a policy name contained an apostrophe.

App Integration Fixes

The following SWA apps were not working correctly and are now fixed:

• Accredible (OKTA-511942)

• SurveyMonkey (OKTA-509109)

Server-generated secret keys lengthened

Server-generated secret keys have been lengthened to enhance security. These keys are used to generate one-time passwords for multifactor authentication in FIPS-enabled environments and orgs.

See Configure Okta Verify options.

Introducing the Progressive Enrollment experience

Typically, collecting end-user data during the initial sign-up process creates friction and abandonment. The addition of the Progressive Enrollment feature helps you to capture the minimum user information required to create a profile and then expand and enhance those user profiles during subsequent sign-in operations. Admins can control what information is collected, validate those input values, and trigger inline hooks during the self-service registration and progressive enrollment flows. See Registration of end users.

Password synchronization for LDAP-sourced users

When the passwords of LDAP-sourced users are reset in Okta and LDAP delegated authentication is enabled, the new password is now immediately synchronized to the user's assigned applications that are configured for password synchronization. This change makes sure that user passwords remain current and reduces the likelihood that users will be unable to access their applications. See Application password synchronization.

Configure sign-on policies based on identity providers

Admins now have the option to configure a sign-on policy based on a specific identity provider. This allows admins more flexibility to dictate which IDP can be used to obtain an Okta session. See Add an authentication policy rule.

Additional detail now provided on the Sign-In Widget

The Verify it’s you with a security method page on the Sign-In Widget now indicates whether a security method is used for authentication, recovery, or both.

Remember my last-used MFA authenticator

Okta now remembers all MFA authenticators that the user selected the last time they successfully signed in. On subsequent sign-in attempts, the last-used authenticator is automatically selected by default. Users can still select another authenticator by clicking Verify with something else. This feature will be gradually made available to all orgs.

SSO capability to OIN apps

Customers who subscribe to the MFA-only package of services now have basic single sign-on functionality to Okta Integration Network apps.

Legacy user group ID support

Validation rules have been relaxed to support user group entity legacy ID formats created prior to 2012.

FIDO2 security key enrollment

Admins may now enroll a FIDO2 security to a user’s account, on their behalf, from the Okta user interface. This enables admins to provide extra levels of assistance in the event that a user is unable to complete the enrollment themselves. See Configure the FIDO2 (WebAuthn) authenticator.

New catch-all rule conditions

The catch-all rule in new authentication policies now allows access with any two factor types and requires re-authentication after 12 hours. See Add a global session policy rule.

OIN Manager developer terms

OIN Manager pages now include links to developer terms and conditions. See Developer Terms.

Session management section for adding a global session policy rule

A new Session management section is available when adding a new global session policy rule or editing an existing one.

The section includes two new options:

• Maximum Okta session lifetime: Set time limit for user sessions.

• Persist session cookies across browser sessions: Allow the user to continue a session after reopening a closed browser.

These options were previously only available through the Okta API, but now they can be configured from the Admin Console also.

Session Expires After is now renamed Expire session after user has been idle on Okta for.

Additional warnings and descriptions clarify the functionality of the fields and how to better configure them.

See Add a global session policy rule.

User.session.start System Log events

A user.session.start System Log event is fired after successful app-specific DelAuth sign-in events.

Default policy new conditions

The default authentication now allows access with any two factor types and requires re-authentication after 12 hours. See Add an authentication policy rule.

Default policy name change

For new and upgrading orgs, the default authentication policy has been renamed Any two factors. This policy allows access with any two factor types and requires re-authentication after 12 hours. See Preset authentication policies.

OIN App Catalog user interface changes

The Languages Supported section of the app details page has been removed.

OKTA-449159

In the Add Identity Provider - Microsoft UI, the Microsoft Scopes help link pointed to an incorrect URL.

OKTA-480772

AD-sourced users who reset their passwords in AD had to reset their passwords again when using IWA or ADSSO to sign in to Okta.

OKTA-498957

When configuring SAML signing certificates for a SAML 2.0 app, admins were unable to right-click and copy the Identity Provider metadata link in the Admin Console.

OKTA-500367

Unique properties associated with non-existent users weren't cleared when user validation failed during user creation.

OKTA-502678

Users who enrolled Okta Verify on multiple devices and clear the Send push automatically checkbox didn't receive a push notification when they selected Get a push notification.

OKTA-506002

Since uniqueness requires exact value matches, making schema properties of type Number unique was an issue and is no longer supported. Use Integer or String properties instead.

OKTA-506333

Warning messages appeared on the Global Session Policy - Add Rule and Edit Rule page even though the relevant fields weren’t visible.

OKTA-507888

On the Pages panel of Customizations > Branding, the Okta defaults appeared instead of an org's selected theme.

OKTA-509079

The Welcome page, SMS reminder prompt, and security image prompt weren't shown for users who accessed Okta using AD SSO in Incognito mode.

OKTA-510254

The profile enrollment form didn't permit more than 10 allowed attributes.

OKTA-510483

Sometimes an error occurred when an admin attempted to edit a resource set that included a deleted app.

App Integration Fixes

The following SWA apps were not working correctly and are now fixed:

• GetFeedback (OKTA-505764)

• GoToWebinar (OKTA-502955)

• NordLayer (OKTA-505977)

Hyperdrive agent, version 1.2.0

Okta for MFA provides more security for Electronic Prescribing for Controlled Substances (EPCS) clinician flows when using the Epic Hyperdrive platform. This plugin is compatible with both Classic Engine and Identity Engine orgs (EPCS clinician flows for customers still using the deprecated Epic Hyperspace platform aren't supported on Identity Engine). See MFA for Electronic Prescribing for Controlled Substances - Hyperdrive and Okta Hyperdrive agent version history.

Okta LDAP agent, version 5.13.0

This version contains:

• An upgraded version of Amazon Corretto

• Security fixes

• Improved handling of exception in poller thread

• Bug fixes

This agent will be gradually made available to all orgs.

See Okta LDAP Agent version history.

JIRA Authenticator Toolkit, version 3.1.9

This version contains:

• Support for Jira 8.22.2

• Bug fixes

See Okta Jira Authenticator Version History.

Okta Browser Plugin, version 6.10.0

This version includes the following fixes:

• Some elements weren't accessible in the Okta Browser Plugin Change password dialog.
• The Okta Browser Plugin briefly displayed a prompt when users opened SWA apps from the dashboard.

See Okta Browser Plugin version history.

Expose groups in the LDAP interface directory information tree (DIT)

To simplify access control decisions for their orgs, admins can now select the groups they want to expose in the LDAP interface directory information tree (DIT). In addition to Okta groups, admins now have the option to view the application groups that are significant to their orgs, including Active Directory (AD) and LDAP groups. See Expose app groups in the LDAP interface directory information tree.

Symantec VIP authenticator now available

The Symantec VIP authenticator is now available in Okta Identity Engine. Enterprises that use Symantec VIP to verify their users’ identities may now integrate this authenticator into their Okta environments and use it to protect access to their Okta orgs and apps. See Configure the Symantec VIP authenticator.

Password as optional authenticator

Passwords are weak authenticators and prone to security issues. Currently all users are required to enroll a password. This also causes friction during the self-service registration process. You can now create a password-optional or passwordless sign-in experience for your end users. It makes the registration process quicker by removing the need to set up a password. It also provides a safer and more secure sign-in experience as users can instead use stronger authenticators such as possession-based authenticators or biometrics. Okta gives you the flexibility to target specific groups of users in your organization with passwordless flows, allowing you to gradually roll out the experience across your entire user base. See Set up passwordless sign-in experience.

Improved email magic link authentication experience

Email magic links have been enhanced to allow end users to authenticate in two different contexts. They can authenticate in the same location where they click the link and quickly return to the application context. Or, if the end user clicks the link in a different browser, they can enter a one-time password to proceed with authentication. Previously when using email magic links to sign in to an application, end users had to return to the original browser location where they initiated the sign-in attempt. Okta ensures that end users can prove ownership of both the originating tab and the tab where they clicked the email magic link. See Configure the Email authenticator and Sign in to resources protected by Okta.

New System Log events

Two new System Log events track when a new authenticator is created and when an existing authenticator is updated:

• security.authenticator.lifecycle.create: This event is recorded when an admin creates a new authenticator for the org. It can be used to identify who created an authenticator and which authenticator was created. The actor specifies the user who created the authenticator and the target specifies the authenticator name and the ID. This event may also contain some authenticator-specific information.

  

• security.authenticator.lifecycle.update: This event is recorded when an admin updates an authenticator in the org. It can be used to identify who updated an authenticator and which authenticator was updated. The actor specifies the user that updated the authenticator and the target specifies the authenticator name and the ID. This event may also contain some authenticator-specific information.

  

System Log events for telephony rate limit violations

Telephony system.sms.send.* and system.voice.send.* events are now issued with a DENY System Log message when SMS or voice messages are blocked due to telephony operational rate limit violations. The system.operation.rate_limit.violation event is still fired but will be deprecated in the 2022.08.0 release.

See System Log.

Enhancements to the base OIDC IdP connector

The generic OpenID Connect (OIDC) identity provider (IdP) connector offers PKCE as an additional verification mechanism. You can also define a regular expression to match Okta usernames when authenticating through this connector. See Create an Identity Provider in Okta.

OIN Manager user interface changes

The OIN Manager includes the following updates:

• The App categories field has been renamed to Use cases to be consistent with the OIN catalog.

• Single Sign-On is the default use case.

JWT claim enhancement

For custom JSON Web Token (JWT) claims, the name portion now supports the URI format, including the slash and colon characters. Any name containing a colon character must be a URI.

System Log enhancement for inline hook types

The inline hook type is now included in the debug data for a System Log debug context event.

Unique names enforced for custom admin roles

When a super admin creates a custom admin role with a duplicate role name, the following error message now appears: There is already an admin role with this name. See Custom admin roles.

Improved text for resource set constraints

On the Create new resource set and Edit resource set pages, the Constrain to all check box labels now include the selected resource type (Constrain to all groups, for example). See Work with the resource set component.

User interface label change

The Device Bound checkbox label on the Authentication Policy Add Rule modal has been changed to Exclude phone and email authenticators. See Add an authentication policy rule.

Additional detail now provided on the Sign-In Widget

The Verify it’s you with a security method page of the Sign-In Widget now displays the name of the app under each security method listed.

User interface help text changes

Enhancements to the help text on the Identity Provider pages align with product changes and improve user experience. See Identity Providers.

User Activation template update

Admins can now add the fromURI to the User Activation email template. This enables user activation from any registered OIDC app in the org.

Help menu updates

In the global help dropdown menu, help links are renamed and now contain resource descriptions.

Global session policy UI updates

UI strings for the global session policy’s authenticator requirements were updated. SeeAdd a global session policy rule.

Policy condition text changes

Enhancements were made to the multifactor authentication items on the Global Session Policy Add Rule modal to improve user experience. See Add a global session policy rule.

System Log enhancements for token exchange flow

A ResponseTime field has been added to the System Log to track the performance of the token exchange flow.

Revised error message for password policy rule updates

Admins now see a clearer error message if they attempt to require additional verification in a password policy rule in which the Email, Phone, or Okta Verify authenticator are used for recovery and no other authenticators are enabled.

OKTA-471339

Creating a new LDAP integration from the App Catalog resulted in a Resource not found error.

OKTA-479711

When a user added or removed from a group with a custom admin role, the System Log displayed a Grant user privilege event.

OKTA-480925

Admins didn’t receive timely email notifications when users locked themselves out of their accounts.

OKTA-482826

Some users imported from Active Directory were stuck in one-time password mode if they were activated more than once.

OKTA-488912

When a super admin searched for a group on the Edit resources to a standard role page, the search results didn’t appear until the admin typed in at least three characters.

OKTA-489049

When admins clicked the Tasks tab on the End-user Dashboard, the page took too long to load and the web browser became unresponsive if there were a large number of entitlements.

OKTA-491194

Deleting a custom attribute created a job that consistently timed out for orgs with a large number of users.

OKTA-491583

When using an OIDC app with refresh tokens, clients could obtain an access token through an existing refresh token if the user consent to the offline_access scope was revoked.

OKTA-493059

Admins couldn't upload certificate chains in tree format.

OKTA-493075

The Admin Role Assignments report sometimes included duplicate records.

OKTA-493119

Some users who attempted to sign in through an external IdP received a rate limit error and couldn't return to the sign-in page.

OKTA-496025

The Delete dialog in the LDAP interface was missing a question mark.

OKTA-497934

The Group Search endpoint didn't reflect the last membership update.

OKTA-498383

Some read-only admins could edit policy assignments.

OKTA-501623

Simultaneous user profile updates and deactivations sometimes resulted in a permanent DEACTIVATING status for the user.

OKTA-501729

When an admin created a new user with the User must change password on first login option selected, the user's status was mistakenly set to ACTIVE instead of PASSWORD_EXPIRED.

OKTA-502404

Users couldn’t temporarily sign in if their org subdomain was changed.

OKTA-502620

In Assign People, users who were removed from the permitted group were still available.

OKTA-503017

On the Profile Enrollment page, admins could delete the Default Policy. After refreshing the page, the default profile enrollment policy was restored, but attempting to edit that policy resulted in a blank page.

OKTA-503377

Users could use ADSSO to sign in to Okta when delegated authentication was disabled.

OKTA-503378

Users could continue to use the Okta IWA Web agent to sign in to Okta when delegated authentication was disabled.

OKTA-503715

The file sizes and hash values displayed on the Downloads page for the Linux RADIUS installers were incorrect.

OKTA-505960H

Admins who clicked the Resources > Help Center link from the Admin Console weren’t automatically signed into the Okta Help Center.

Okta AD agent, version 3.11.0

This version of the agent contains the following changes:

• Increased minimum .NET version supported to 4.6.2. If the installer doesn't detect .NET 4.6.2 or higher, it won't be installed.

• Security enhancements

• Removed unsupported libraries

See Okta Active Directory agent version history.

Okta ADFS plugin, version 1.7.10

This version of the plugin contains bug fixes and security enhancements. See Okta ADFS Plugin version history.

Okta RADIUS agent, version 2.17.4

This version of the agent contains bug fixes and security enhancements. See Okta RADIUS Server Agent Version History.

Okta On-Prem MFA agent, version 1.5.0

This version of the agent contains security enhancements. See Okta On-Prem MFA Agent Version History.

Jira Authenticator, version 3.1.8

This release contains bug fixes. See Okta Jira Authenticator Version History.

Okta Resource Center access

The Okta Resource Center is a collection of product tours, step-by-step guides, and announcements that helps you learn about new features and how to perform tasks within the Admin Console. You can launch the Okta Resource Center by clicking the blue icon from anywhere in the Admin Console. See Okta Resource Center.

Use Okta MFA for Azure AD Conditional Access and Windows Hello for Business Enrollment

You can use Okta MFA to:

• Satisfy Azure AD Conditional Access MFA requirements for your federated Office 365 app instance.
• Enroll end users into Windows Hello for Business.

See Use Okta MFA for Azure Active Directory.

Sign-In Widget enhancements for self-service password reset and default registration page

Okta has enabled the self-service password reset function for embedded authorization on all new and upgraded Identity Engine orgs. For integrations using embedded authentication, client applications can now use a recovery token when launching the Sign-In Widget to start the recovery flow. In addition, a new endpoint at /{orgurl}/signin/register gives you the ability to point your Sign-In Widget directly to the registration page for default applications.

Client secret rotation and key management

Rotating client secrets without service or application downtime is a challenge. Additionally, JSON Web Key management can be cumbersome. To make client secret rotation a seamless process and improve JWK management, you can now create overlapping client secrets and manage JWK key pairs in the Admin Console. You can also create JWK key pairs from the admin console without having to use an external tool. See Manage secrets and keys for OIDC apps.

Personal Identity Verification

Personal Identity Verification is now supported on Okta Identity Engine. See Add a Smart Card IdP.

Okta API access with OAuth 2.0 for Org2Org

Previously, the Org2Org integration only supported token-based access to the Okta API. You can now configure the Org2Org integration to access the Okta API as an OAuth 2.0 client. This increases security by limiting the scope of access and providing a better mechanism to rotate credentials. See Integrate Okta Org2Org with Okta.

Custom help links in the Sign-In Widget

Admins can add a custom help link on the authenticator page of the Sign-In Widget. This link can provide just-in-time help with multifactor authentication and can point to an in-house resource or other location. See Customize text on your sign-in page.

PKCE is a verification method for OIDC SPA and Native app integrations

The OIDC App Integration Wizard now identifies that PKCE is not a client authentication method. Instead, for SPA and Native apps, the AIW creates apps listing PKCE as a verification method. See Create OIDC app integrations.

Add agent permissions to custom admin roles

Custom admins can perform AD agent auto-updates for AD instances they have access to. They can also view the agents dashboard page to see the statuses of all agents associated with app instances they can manage. See Automatically update Okta Active Directory agents.

Group count tooltip on the Admin Dashboard

On the Admin Dashboard, the Overview section now provides an "Includes only Okta sourced groups and excludes those sourced externally, such as AD groups" tooltip for the Groups count. The new tooltip helps you understand how your groups count is calculated. You can view the tooltip by hovering your cursor over the Groups count on the Overview section. See View your org at a glance.

Okta End-User Dashboard enhancements

• Unread notifications are more visible to users.

• The End-User Dashboard Preview function bar has moved to a separate dialog. See Preview an end user's dashboard.

• The Last sign in link at the bottom of the Okta End-User Dashboard now includes the entire text of the message in the hyperlink.

• The title of the copy password dialog in the Okta End-User Dashboard is more specific.

System Log enhancements for block zone events

• The zone.make_blacklist event in the System Log now encompasses two actions: when an admin creates a blocked network zone, and when an admin marks an existing blocked zone as unblocked. Previously, this event was only recorded when a pre-existing network zone was converted into a block list.

  

• The zone.remove_blacklist System Log event now encompasses two actions: when a network zone is converted into an allow list, and when an admin deletes a blocked zone. Previously, this event was only recorded when a pre-existing network zone was converted to an allow list.

  

System Log enhancement for network zone events

A network zone ID is now added as a target for all network zone events in the System Log.

Enhancements to ThreatInsight

ThreatInsight is improved to further protect rate limit consumption from malicious actors. Requests from actors with a high threat level continue to be logged and/or blocked depending on the org's configuration. Now, additional requests that seem malicious but have a lower threat level no longer count towards org rate limits.

Enhancements to multifactor authentication validation in authentication policies

When creating authentication policies, admins can only select authenticators that are enabled in their org and available to the associated group of users.

OIN Catalog enhancements

Integrations in the OIN Catalog help end users address issues across a variety of industries. Okta has added the ability to filter integrations by industry to help both prospective and current Okta users identify the OIN integrations that best meet their needs. Additionally, the OIN Catalog interface has been updated with the following enhancements for improved navigation:

• The search interface has been updated and popular search terms can now be selected.

• Details pages for integrations have been updated for usability.

• Navigation breadcrumbs have been added to the OIN Catalog.

• Integrations can now be sorted alphabetically and by recently added.

See Add existing app integrations.

OIN Catalog search functionality and filter updates

• OIN Catalog search results now prioritize complete word matches from the search phrase.

• Integrations in the OIN Catalog can now be filtered by RADIUS functionality.

See Add existing app integrations.

OIN Manager enhancements

The OIN Manager now requires that ISV submissions for SCIM integrations confirm that the integration meets API response timing requirements. See Publish an OIN integration.

OKTA-386570

If an LDAP interface bind request failed, subsequent searches failed with an internal server error instead of a permissions denied error.

OKTA-435855

Web and SPA app integrations created with an Authorization code or Interaction code grant type incorrectly returned an error if the Login Initiated By Either Okta or App option was selected.

OKTA-476570

The System Log didn’t display the app name when users entered invalid credentials during an SP-initiated flow.

OKTA-476896

On the Administrators page, deactivated users with assigned admin roles were included in the Individually assigned count.

OKTA-477494

Some invalid EL expressions incorrectly passed validation.

OKTA-477634

Some users experienced delays when searching for an app on the Okta End-User Dashboard.

OKTA-481752

When users tried to enroll in Okta Verify, VoiceOver screen readers didn't highlight the mobile device type correctly or allow users to select a device. It also selected the iPhone option even though the Android option was also available.

OKTA-482266

During PIV authentication where no certificate or an expired certificate was provided, a 404 error was displayed.

OKTA-482435

When admins upgraded an app to SAML 2.0, the SAML 2.0 setup instructions used the org-scoped certificate instead of the app-scoped certificate.

OKTA-483062

Custom application access error pages redirected to the default Okta error page.

OKTA-484366

Admins couldn’t use the objectGuid attribute as a unique identifier when integrating AD LDS LDAP servers with Okta.

OKTA-486141

If an inline hook was registered and in use under a profile enrollment policy, admins could deactivate or delete the hook. This resulted in an error when that policy was used for self-service registration.

OKTA-486974

An internal ID incorrectly appeared in a policy System Log event.

OKTA-488233

Parallel JIT requests for the same username created duplicate users.

OKTA-488234

The sign-in page didn’t load correctly for some orgs after they upgraded to Identity Engine.

OKTA-488428

Some users lost the ability to reveal passwords for an app when the app drawer feature was enabled.

OKTA-488663

When Full Featured Code Editor was enabled, the full screen toggle on the error page code editor didn’t change to a minimize icon.

OKTA-489050

Sometimes an error message was displayed when admins viewed applications in the Admin Console.

OKTA-489448

In SP-initiated flows, the message instructing users to create their accounts was formatted incorrectly.

OKTA-490811

When an unenrolled device attempted to access an app that required device management, the sign-in request didn't fail gracefully.

OKTA-491164

Some admins weren’t assigned the Admin Console when they were added to a group with assigned admin roles.

OKTA-491264

Sometimes when a super admin deleted a custom admin role that contained email notifications, admins couldn’t update their email notification settings.

OKTA-495549

When groups were exposed in the LDAP interface directory information tree, some filters referencing the entryDn attribute returned the incorrect result code if the group wasn’t found.

OKTA-495598

AD-sourced users who reset their passwords in AD had to reset their passwords again when using IWA or ADSSO to sign in to Okta.

App Integration Fix

The following SWA app was not working correctly and is now fixed:

• NDFR/SDU (OKTA-485335)

Okta On-Prem MFA Agent, version 1.4.9

This version of the agent contains security enhancements. See Okta On-Prem MFA Agent Version History.

Okta Browser Plugin, version 6.9.0 for all browsers

This version includes the following changes:

• Keyboard navigation didn't work properly when users attempted to switch to a new app list in the plugin popover window. Users were unable to close the plugin popover window with keyboard input.
• Version 6.8.0 of the plugin caused issues for some users when they attempted to sign in to an SWA app in an iframe.

See Okta Browser Plugin version history.

Admin Experience Redesign toggle removed

The toggle that allowed super admins to switch between the Admin Experience Redesign and the old experience has been removed. All Okta admins now benefit from our restyled Okta Admin Dashboard, responsive navigation side bar, and modern look and feel.

Allow or deny custom clients in Office 365 sign-on policy

You can filter specific clients in an Office 365 app sign-on rule to allow or deny them access to Office 365 resources. This filter can be used to deny access to untrusted clients or to only allow trusted clients. See Allow or deny custom clients in Office 365 sign on policy

Endpoint integrations

The Device Integrations page now includes an Endpoint Security tab, which allows Admins to manage endpoint integrations with Windows Security Center and CrowdStrike. Endpoint Detection and Response (EDR) integration extends device posture evaluation by enabling Okta Verify to capture signals collected by your EDR client running on the same device. See Endpoint security integrations.

Okta FastPass enhancement

With Okta FastPass, an error now appears in the Sign-In Widget if User Verification is not provided when it is required.

Improved AD group membership synchronization

The ADAppUser distinguished name field is now updated when a user is added to an Okta group and a matching group exists in AD. When an Okta provisioning request moves a user to a new organizational unit, the change is quickly duplicated in AD. This new functionality helps ensure the accuracy and integrity of AD group membership information. Manage Active Directory users and groups.

New App Drawer

The updated app settings panel on the Okta End-User Dashboard allows end users to see all app details in a single view without having to expand multiple sections. End users can quickly differentiate between SWA apps where they have set a username and password and SAML / OIDC apps that are admin-managed with no additional user settings. The updated app settings panel also provides accessibility improvements with better screen reader support and color contrast. See View the app settings page.

ShareFile REST OAuth

Admins can now upgrade to the latest version of our ShareFile integration. OAuth provides more secure authentication and will be now used for Provisioning and Imports. See Configure ShareFile OAuth and REST integration. This feature is made available to all orgs.

Recent activity page link for end users

If Recent Activity is enabled, users can click Last sign in in the footer of the left navigation bar to go directly to the Recent Activity page.

Burst rate limits available on Rate Limit Dashboard

The Rate Limit Dashboard, available from the Admin Console, now includes data on burst limits in your Okta org, in addition to rate limit warnings and violations. The Violations dashboard was renamed Events to acknowledge the increase of scope, and includes the ability to filter on timeline as well as the type of event (warning, burst, and violation). Hovering over the burst rates in the graphs provides more detail and links to the system log for individual endpoint calls. The individual Usage graphs provide details on bursts for the individual API. See Rate limit dashboard and Burst rate limits.

New ThreatInsight enforcement action

If you configure ThreatInsight to log and enforce security based on the threat level detected, ThreatInsight can either limit or block authentication requests from suspicious IP addresses. For example, if a specific IP address is suspected of malicious activity but the threat level is considered low, authentication requests from the IP address are not denied access but might be subjected to a rate limit. See Configure Okta ThreatInsight.

PIV IDP user profile mapping

You can now use idpuser.subjectUid in an Okta user profile when mapping IDP Username for Personal Identity Verification (PIV) IDPs. See Add a Smart Card Identity Provider.

Default policy updates

The Default Global Session Policy and the default authentication policy now allow access to users with any two factors. See Global session policies.

Global Session Policy default rule

Admins can now edit the primary factor condition in the default rule of their org’s Default Global Session Policy. See Edit a global session policy.

Custom app logo preview

Admins can now preview a custom logo before applying it to an app. See Customize an application logo.

Updated error message for Microsoft Graph API

An error message for Microsoft Graph API has been updated to include more details and a possible workaround.

Debug logging for token exchange

The following fields have been added to the System Log for assistance in debugging OAuth2 token exchange events:

• requested_token_type
• subject_token_type
• actor_token_type
• resource

Updated SAML setup instructions

Setup instructions for SAML 2.0 apps now use per app SHA2 certificate during the app creation.

Change to the number of free SMS messages allowed

To balance growing costs of SMS usage while maintaining a commitment to developer and free trial orgs, Okta is changing the number of free SMS messages these orgs are allowed each month. Beginning April 4, 2022, orgs may send a maximum of 100 messages per month. For more information about this change, visit the Okta Developer Community.

OKTA-442031

Some Okta Mobile sign-in flows didn’t work for admins when the Okta Admin Console app required step-up authentication.

OKTA-456484

When more than one authenticator appeared on the authenticator enrollment page, the Return to authenticator list link didn’t appear.

OKTA-460284

SAP Litmos imports failed with an unexpected error.

OKTA-467278

If an error occurred in Okta Verify during authentication or if authentication was cancelled, a delay occurred before the user was prompted again to select a security method.

OKTA-472816

When app admins selected the Agents tab, the error message “Error rendering agents monitor table” appeared and no agents were listed.

OKTA-473180

Sometimes AssertionId for SAML1.1 assertions was poorly formatted.

OKTA-475767

Sometimes, in the Groups page Description column, an equals sign (=) replaced the forward slash ( / ) in LDAP-sourced group names.

OKTA-475774

Users could use ADSSO to sign in to Okta when delegated authentication was disabled.

OKTA-478467

Admins who didn’t have permission to view the Agent monitors page received agent auto-update email notifications.

OKTA-478537

When admins searched for an authentication policy, only the first 100 policies were visible. This occurred on both the Applications page and the Authentication policies page.

OKTA-479110

The sender email address on the Customizations > Emails page was inconsistent with the sender email address on individual templates.

OKTA-479701

Admins were shown events that were unrelated to their account in the Security Events section of the Recent Activity page.

OKTA-482086

Some admins saw an error if they tried to run a report using resource sets created more than a year ago.

OKTA-483011

Sometimes, Okta IWA agent authentications failed during deployment when IWA replay attack detection was enabled.

App Integration Fixes

The following SWA apps were not working correctly and are now fixed:

• MyFonts (OKTA-476809)

• Quickbooks Time Tracker (OKTA-476695)

Okta Active Directory Password Sync agent, version 1.5.0

This version of the agent includes:

• Security enhancements.

• Making .NET Framework 4.6.2 the minimal supported version. Earlier versions are automatically upgraded during agent installation.

• Okta Military Cloud support.

See Okta Active Directory Password Sync Agent version history.

Okta AD agent, version 3.10.0

This version of the agent contains:

• Okta Military Cloud support.

• Bug fixes.

See Okta Active Directory agent version history.

Okta LDAP agent, version 5.12.0

This version of the agent contains support for Okta Military Cloud. See Okta LDAP Agent version history.

Event hooks for custom admin roles

Custom admin role events are now available for use as Event Hooks. This provides more security to admins by ensuring that they have the correct permission to perform tasks. See Event hooks.

Enforce limit and log per client mode for OAuth 2.0 /authorize and /login/login.htm endpoints

The default client-based rate limit for OAuth 2.0 /authorize and /login/login.htm endpoints is now elevated to Enforce limit and log per client (recommended) mode. This means that if your org’s client-based rate limit was previously set to Do nothing or Log per client, the setting is changed to Enforce limit and log per client (recommended) mode.

Note that based on the email communication sent out on Feb 3, 2022 and Feb 25, 2022, these changes are not applicable to certain orgs. See Default client-based rate limit mode change.

New ThreatInsight enforcement option

ThreatInsight evaluates authentication requests to detect potentially malicious activity from IP addresses exhibiting suspicious behavior. If you enable the Log and enforce security based on threat level option, ThreatInsight can limit or block authentication requests from suspicious IP addresses based on the threat level detected. For example, if a specific IP address is suspected of malicious activity but the threat level is considered low, authentication requests from the IP address are not denied access but might be subjected to a rate limit. The rate limit helps ensure that requests from a suspicious IP address don't overload authentication services and affect legitimate traffic. However, if an IP address is suspected of malicious activity and the threat level detected is high, authentication requests from the IP address are blocked. See Configure Okta ThreatInsight.

Validation for custom message templates

If you customize the default SMS message template, the Admin Console checks the message to determine whether it contains GSM or non-GSM characters and enforces the GSM or non-GSM character limit before saving the message. This check ensures that you don't create custom SMS messages that exceed the GSM or non-GSM character limit for message segments.

If you change existing custom templates, the new restrictions are enforced if your messages contain non-GSM characters.

For more information about customizing SMS templates, see Configure and use telephony.

Sign-In Widget updates for Okta FastPass

The Sign in with Okta FastPass button no longer appears on the Sign-In Widget when users access Android Native apps that use Webview. Webview doesn't support this functionality.

Copy button updates

In the app settings panel of the Okta End-User Dashboard, the copy buttons for the username and password fields are renamed Copy username and Copy password.

OKTA-447833

Admins couldn’t set up a custom domain URL with a top-level domain of .inc.

OKTA-455641

The Edit Assignment page for the Box app didn’t handle non-alphabetical characters properly.

OKTA-466022

Admins whose custom role contained the Run imports permission couldn’t view their org’s LDAP integrations.

OKTA-468707

The System Log didn't display ThreatSuspected=false for authentication events when no threat evaluation was done.

OKTA-468751

When Okta Verify was the only enrolled authenticator, time-based one-time password (TOTP) wasn’t automatically selected even though it was the last-used authentication method.

OKTA-471299

When ThreatInsight evaluated sign-in attempts for unknown users, the threat level was incorrectly displayed as threatLevel=UNKNOWN in the System Log.

OKTA-471605H

In SP-initiated flows, users' sessions ended when they closed the browser even if they selected Keep me signed in.

OKTA-471815

Some customers noticed duplicate Windows devices on the Devices page when users re-enrolled with Okta Verify.

OKTA-471605H

In SP-initiated flows, users' sessions ended when they closed the browser even if they selected Keep me signed in.

OKTA-472304H

Group push for some customers resulted in a timeout error after one minute.

OKTA-473512

When the Custom Admin Roles feature was enabled, super admins were called Super Organization Administrators.

App Integration Fixes

The following SWA app were not working correctly and are now fixed:

• Asana (OKTA-467306)
• Dashlane Business (OKTA-466333)
• Guardian Insurance (OKTA-470966)
• Loop11 (OKTA-471181)
• Names & Faces (OKTA-468537)
• Nord Layer (OKTA-469771)
• Optum Health Financial (OKTA-465956)
• QuickBooks (OKTA-467864)
• Twitter (OKTA-470889)

OKTA-419847

On-Prem MFA API tokens contained scopes beyond what was required for agent operation.

OKTA-433751

End users received errors when accessing SWA apps through the Okta End-User Dashboard if their app passwords contained ampersands.

OKTA-436486

Some orgs couldn’t save email templates containing Velocity variables. This occurred for orgs with Enhanced Email Macros enabled.

OKTA-442296

Some end users received a 400 error after signing in to the Okta End-User Dashboard.

OKTA-443777

Admins couldn’t use the objectGuid attribute as a unique identifier when integrating AD LDS LDAP servers with Okta.

OKTA-451206

When admins enabled LDAP real-time synchronization, the system.agent.ad.realtimesync event erroneously appeared in the System Log.

OKTA-455372

If the information required to evaluate behavior was not available, the System Log displayed BAD_REQUEST for rules that included behavior detection.

OKTA-456046

When upgrading to Identity Engine, orgs received an error stating that they had Sharepoint On-Premises app instances that weren't supported by Identity Engine.

OKTA-459571

In the admin console, the status of RADIUS agents randomly changed from Operational to Disrupted.

OKTA-459778

Customized Sign-In Widgets didn’t match the preview on the Sign-In Widget code editor.

OKTA-460366

On Security > Networks > Add IP Zone, proxy IP addresses weren't explicitly identified as trusted proxy IP addresses.

OKTA-461015

Event information was missing from the Report Suspicious Activity page after users changed their password in the Sign-In Widget.

OKTA-461198

When the Custom Admin Roles feature was enabled, read-only admins could see the Assign to People, Assign to Groups, and Edit User buttons on the Applications page.

OKTA-462025

Admins who refreshed a page in the custom URL domain wizard weren’t returned to the correct step.

OKTA-462114

The ${user.login} variable appeared in default email templates.

App Integration Fixes

The following SWA apps were not working correctly and are now fixed

• AppSplit (OKTA-462294)
• Auth0 (OKTA-456042)
• Dockerhub (OKTA-463515)
• FinServ (OKTA-463959)
• LoansPQ (OKTA-462410)
• MeridianLink LoansPQ (OKTA-460940)
• New Relic (OKTA-464710)
• ProtonMail (OKTA-463545)
• Salto Keys (OKTA-464469)
• WePay (OKTA-462296)
• Wikispaces (OKTA-462300)

Okta On-Prem MFA agent, version 1.4.8

This version of the agent contains security fixes. See Okta On-Prem MFA Agent Version History.

Okta Active Directory agent, version 3.8.0

This version of the agent contains:

• Agent auto-update support
• Improved logging functionality to assist with issue resolution
• Bug fixes

See Okta Active Directory agent version history.

Okta RADIUS Server agent, version 2.17.2

This version of the agent contains security fixes. See Okta RADIUS Server Agent Version History.

Admin Console user interface changes

On the Device Integrations page, the Endpoint Management tab now includes an Activate/Deactivate action for legacy Device Trust desktop configurations. It also includes a warning message if an admin attempts to deactivate Device Trust when their Identity Engine app sign-on policy is not configured correctly for devices that are not trusted.

Delivery status of SMS messages in the System Log

Administrators can now view the delivery status for SMS messages in the System Log. For information about the new event type, see Configure and use telephony.

Feature name change: New Sign-On Notification

The New Device Notification functionality is renamed to New Sign-On Notification in the Admin Dashboard, the email notification title, and elsewhere. It refers to the email notification a user receives when there’s a sign-in event from an unrecognized device.

New permissions for custom admin roles

The following new permissions can now be assigned to a custom admin role:

• Activate users

• Deactivate users

• Suspend users

• Unsuspend user

• Delete users

• Unlock users

• Clear user sessions

• Reset users' authenticators

• Reset users' passwords

• Set users' temporary password

• Run imports.

The new permissions give super admins more granular control over their delegated org permissions. See About role permissions.

YubiKey OTP authentication now available

YubiKey one-time-password (OTP) mode authentication is now available to Okta Identity Engine users. See Configure the YubiKey OTP authenticator

Password change notifications for LDAP-sourced users

Password change email notifications may now be sent to LDAP-sourced users.

API token ID displayed in tokens

API token ID is now displayed under API tokens for easy tracking.

SHA type displayed for SAML certificates

SHA type is now displayed for SAML certificates in the Admin Console.

New System Log event

A new policy.mapping.create event is added to the System Log for profile enrollment and app sign-on policies.

OKTA-420065

Launch on sign-in apps on the Okta End-User Dashboard launched multiple times after the user signed in.

OKTA-448006

Some branded pages used an org’s previously uploaded logo rather than their new theme logo.

OKTA-452612

User context wasn’t included in some orgs' token inline hook request data.

OKTA-453969

Some Duo users were unable to authenticate after upgrading to Okta Identity Engine.

OKTA-454206

Some admins without super admin permissions could view a link to the Admin role assignments report. This occurred for orgs with the Custom Admin Roles feature enabled.

App Integration Fixes

The following SWA apps were not working correctly and are now fixed:

• Bendigo Bank (OKTA-454211)

• EdgeCast (OKTA-453148)

• Maxwell Health (OKTA-454213)

• My T-Mobile (OKTA-455732)

• Redis (OKTA-454218)