Production release notes

January 2023

2023.01.0: Monthly Production release began deployment on January 17

* Features may not be available in all Okta Product SKUs.

Generally Available Features

New Features

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

Revoke user sessions

Admins can end all Okta sessions for an end user when resetting their password. This option protects the user account from unauthorized access. If policy allows, Okta-sourced end users can choose to sign themselves out of all other devices when performing self-service password reset or resetting their passwords in Settings. See Revoke all user sessions. This feature is now enabled by default for all orgs.

Directory Debugger for Okta AD and LDAP agents

Admins can now enable the Directory Debugger to provide Okta Support with access to Okta AD and LDAP agent diagnostic data. This new diagnostic and troubleshooting tool accelerates issue resolution by eliminating delays collecting data and improves communication between orgs and Okta. See Enable the Directories Debugger. This feature is being re-released.

Non-associated RADIUS agents deprecated

Access for RADIUS agents that have not been associated with an application has now been disabled. See RADIUS integrations.

Unusual telephony requests blocked by machine-learning measures

SMS and voice requests are now blocked if an internal machine-learning-based toll fraud and abuse-detection model considers the requests unusual. Telephony requests that are blocked by the machine-learning model have a DENY status in the System Log.

Enhancements

View last update info for app integrations and AD/LDAP directories

Admins can view the date an app integration was last updated by going to Applications > Applications and selecting the integration. They can view the date an AD/LDAP directory integration was last updated by going to Directory > Directory Integrations and selecting the integration.

Internet Explorer 11 no longer supported

A new banner has been added on the End-User Dashboard to notify the Internet Explorer 11 users that the browser is no longer supported.

MFA report column selection

In the MFA Enrollment by User report, you can now choose which columns to hide or show in the data table. See MFA Enrollment by User report.

Early Access Features

New Features

Enhanced Admin Console search

The Admin Console search now displays your search results in a user-friendly drop-down list. The list provides Top results, People, Apps, and Groups filters so you can quickly and easily find what you’re looking for. See Admin Console search.

Optional consent settings for OAuth 2.0 scopes

OAuth 2.0 Optional Consent provides an Optional setting that enables a user to opt in or out of an app's requested OAuth scopes. When Optional is set to true, the user can skip consent for that scope. See Create API access scopes .

Enhancements

AWS region support for EventBridge Log Streaming

EventBridge Log Streaming now supports all commercial AWS regions.

Fixes

General Fixes

OKTA-437264

The HEC Token field wasn't displayed correctly in the Splunk Cloud Log Stream settings.

OKTA-454996

Some users were able to access apps on non-managed devices.

OKTA-519198

Groups and apps counts displayed on the Admin Dashboard weren't always correct.

OKTA-543969

Accented characters were replaced with question marks in log streams to Splunk Cloud.

OKTA-548780

Custom domain settings were deleted during editing if the admin chose the option Bring your own certificate.

OKTA-553006

When authenticated users attempted to access an app they weren’t assigned to, they were redirected to a sign-in page with a permission error.

OKTA-553364

The Custom Authenticator allowed Android users to sign in without biometric verification even though user verification was required.

OKTA-557762

In some cases when Okta Verify wasn’t active, users couldn’t access apps if the authentication policy had OS version conditions for device assurance.

OKTA-559571

The Help link on the Administrators page directed users to the wrong URL.

OKTA-561259

On the Edit role page, the previously selected permission types weren’t retained.

OKTA-561309

A misleading error message appeared when the authentication policy rule’s possession requirements required an unavailable authenticator.

OKTA-564264

Notifications for adding or renewing fingerprint authentication were sometimes not managed correctly.

Applications

Application Update

New GitHub Teams API URL: In response to GitHub's plan to sunset deprecated Teams API endpoints over the coming months, our GitHub integration has been updated to use the new /organizations/:org_id/team/:team_id path. No action needed for Okta admins.

New Integrations

OIDC for the following Okta Verified applications:

Weekly Updates

December 2022

2022.12.0: Monthly Production release began deployment on December 12

* Features may not be available in all Okta Product SKUs.

Generally Available Features

New Features

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.

Enhancements

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.

Early Access Features

New Features

Transactional verification with CIBA

Organizations are constantly looking for ways to offer a frictionless user experience without compromising security. It becomes even more challenging when the users try to perform sensitive transactions. Okta uses Client-initiated Backchannel Authentication (CIBA) to provide customers with a simple and secure transaction verification solution.

CIBA extends OIDC to define a decoupled flow where the authentication or transaction flow is initiated on one device and verified on another. The device in which the transaction is initiated by the OIDC application is called the consumption device and the device where the user verifies the transaction is called the authentication device. See Create OIDC app integrations.

Fixes

General Fixes

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)

Applications

Application Update

The Update user attributes feature is added to the Lucca Provisioning integration.

New Integrations

New SCIM Integration applications

The following partner-built provisioning integration apps are now Generally Available in the OIN Catalog as partner-built:

SAML for the following Okta Verified applications:

  • Brex (OKTA-540264)

  • Loom (OKTA-551214)

  • NeuralLegion (OKTA-545950)

  • RudderStack (OKTA-552363)

  • ZoomInfo (OKTA-543975)

OIDC for the following Okta Verified applications:

Weekly Updates

November 2022

2022.11.0: Monthly Production release began deployment on November 14

* Features may not be available in all Okta Product SKUs.

Generally Available Features

New Features

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 Add 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.

Enhancements

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.

Early Access Features

New Features

Phishing-resistant authenticator requirement

To enhance security, admins may now require users to authenticate using a phishing-resistant authenticator when enrolling additional authenticators. This feature protects the authenticator enrollment process from phishing attempts. See Require phishing-resistant authenticator to enroll additional authenticators.

API Service Integrations

Using a more secure OAuth 2.0 connection than access tokens, this integration type uses the Core Okta API to access or modify resources like System Logs, apps, sessions, and policies. See API Service Integrations.

Enhancements

Log Stream event structure update

For consistency the report structure for Log Stream events is now the same as that for System Log events. The following fields are changed and might need updating for any monitoring scripts in use:

  • Under devices, osPlatform is now platform.

  • The ipChain array is now correctly nested under request instead of client.

  • The extraneous field insertionTimestamp is removed.

Fixes

General Fixes

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.

Applications

New Integrations

New SCIM Integration application:

The following partner-built provisioning integration app is now Generally Available in the OIN Catalog as partner-built:

SAML for the following Okta Verified applications:

  • Legl (OKTA-525334)

  • WorkOS (OKTA-527211)

OIDC for the following Okta Verified applications:

Weekly Updates