On this page

Identity Engine

May

Weekly release 2022.05.1

Change Expected in Preview Orgs
User-scoped MyAccount API is EA in Preview May 11, 2022
Progressive Enrollment is EA in Preview May 11, 2022
The API for suppressing email notifications is EA in Preview May 11, 2022
Bug fixed in 2022.05.1 May 11, 2022

User-scoped MyAccount API is EA in Preview

The MyAccount API now provides user-scoped endpoints that don’t require admin tokens. The new endpoint is /idp/myaccount. End users only need a bearer token to update their email and phone authenticators. In addition, app developers can call the MyAccount API for active users outside of the authentication context. For example, after a user enrolls in the mandatory email factor and completes authentication, app developers can call the API to enroll the active user with the optional phone authenticator. See MyAccount API.

Progressive Enrollment is EA in Preview

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 continually build out 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 (opens new window) and Registration Inline Hook.

The API for suppressing email notifications is EA in Preview

This API allows you to change who receives email notifications for each individual email template. You can suppress them completely, or send them to admins only. This unlocks testing scenarios that warrant using production user directories, and prevents end users from getting test emails. It also allows extensibility for customers who would like to use a third party email sender through Hooks or Workflows. See Email template settings.

Bug fixed in 2022.05.1

When role target operations included an invalid roleId, an incorrect 500 system error was returned. (OKTA-487507)

Monthly release 2022.05.0

Change Expected in Preview Orgs
Email Address Bounces API is GA in Preview March 2, 2022
Trusted Origins for iFrame embedding is EA in Preview May 4, 2022
Authorize requests to generic OIDC IdPs now include nonce parameter May 4, 2022
Signed request support for generic OIDC IdP is GA in Production March 2, 2022
Client secret rotation and key management is GA in Production February 3, 2022
Okta API access with OAuth 2.0 for Org2Org is GA in Production February 16, 2022
New permissions for custom admin roles May 4, 2022
Password as an optional authenticator is EA in Preview March 30, 2022
Bugs fixed in 2022.05.0 May 4, 2022

Email Address Bounces API is GA in Preview

Okta admins can now control the bounced email address list through the Email Address Bounces API. When Okta-sent email addresses are blocked from an email service (the bounced email list), admins can use this API to create a list of blocked email addresses to be removed from the email service. Note: This API is not available in Free Trial and Developer orgs.

Trusted Origins for iFrame embedding is EA in Preview

You can now choose what origins can embed Okta sign-in pages and 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 allow 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. See Trusted Origins API.

Authorize requests to generic OIDC IdPs now include nonce parameter

For generic OIDC IdPs, a randomized nonce parameter is now included in all authorize requests. The nonce value is sent to the IdP and can be verified in the returned ID Token. See Identity Providers API.

Signed request support for generic OIDC IdP is GA in Production

When customers integrate Okta with an OIDC-based IdP, Okta asks the IdP to authenticate the user with request elements that are passed as query parameters in the URL. The new Signed Request Object allows customers to send these parameters encoded in a JWT instead, improving security on the authorization request sent to the OIDC provider or authorization server.

Client secret rotation and key management is GA in Production

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.

Okta API access with OAuth 2.0 for Org2Org is GA in Production

The Okta Org2Org integration enables you to push and match both users and groups from one Okta org to another. Previously, this 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.

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 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 ORN Resource Sets in the Role assignment concept and the Resource Set object in the Administrator Roles API.

Password as an optional authenticator is EA in Preview

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 Create User with Optional Password enabled.

Bugs fixed in 2022.05.0

  • Web and SPA app integrations using the OIDC API with the Login Initiated By feature incorrectly returned an error if they were created using an authorization_code or interaction_code grant type. (OKTA-435855)

  • If the Administrator Roles API (users and groups) endpoints contained an invalid role type, an HTTP 500 Internal Server Error was returned. (OKTA-393032)

  • Custom email address attribute mapping for the GitHub IdP failed due to a conflict in the id external attribute. (OKTA-460058)

April

Weekly release 2022.04.3

Change Expected in Preview Orgs
Bug fixed in 2022.04.3 April 20, 2022

Bug fixed in 2022.04.3

  • When an unsupported constraint was added to the authentication policy verification method, an error wasn't returned from the Policy API. (OKTA-434893)

Weekly release 2022.04.1

Change Expected in Preview Orgs
Bugs fixed in 2022.04.1 April 6, 2022

Bugs fixed in 2022.04.1

  • An HTTP 500 internal server error sometimes occurred after saving an app instance. (OKTA-483001)

  • Active Directory email activation templates that were translated for the Japanese, Korean, and Chinese languages didn’t render correctly. (OKTA-469764)

  • An OIDC app couldn’t be updated for an IdP-initiated login with Okta flow when the Initiate login URI field in the Admin Console was empty. (OKTA-447112)

Monthly release 2022.04.0

Change Expected in Preview Orgs
Improved email magic link authentication experience is EA in Preview March 30, 2022
Password as an optional authenticator is EA in Preview March 30, 2022
Native SSO support is EA in Preview March 30, 2022
Telephony Inline Hook is EA in Preview March 30, 2022
Splunk available for Log Streaming is EA in Preview March 30, 2022
Burst rate limits available on Rate Limit Dashboard March 30, 2022
OAuth 2.0 Push Authorization Requests March 30, 2022
Signed request support for generic OIDC IdP is GA in Preview March 02, 2022
Okta Org2Org integration supporting Okta API access using an OAuth 2.0 client is GA in Preview February 16, 2022
Client secret rotation and key management is GA in Preview February 03, 2022
Bug fixed in 2022.04.0 March 30, 2022

Email magic links are enhanced to allow end users to authenticate in two different contexts. The end user can authenticate using 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. See Okta email (magic link/OTP) integration guide and Use redirect auth with the Identity Engine sample apps.

Password as an optional authenticator is EA in Preview

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 Create User with Optional Password enabled.

Native SSO support is EA in Preview

Single Sign-On (SSO) between browser-based web apps is achieved by leveraging shared cookies. Unlike web applications, native applications can't use web cookies. With Native SSO, Okta offers a token-based approach to achieve SSO between native applications.

Native SSO allows you to protect native OpenID Connect applications, such as desktop apps and mobile apps, and achieve SSO and Single Logout (SLO) between these applications. See Configure SSO for native apps.

Telephony Inline Hook is EA in Preview

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. 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 Telephony Inline Hook with Twilio.

Splunk available for Log Streaming is EA in Preview

Many organizations use third-party systems to monitor, aggregate, and act on the event data in Okta System Log events.

Log Streaming enables Okta admins to more easily and securely send System Log events to a specified system such as the Splunk Cloud in near real time with simple, pre-built connectors. Log streaming scales well even with high event volume, and unlike many existing System Log event collectors, it does not require a third-party system to store an Okta Admin API token. See Splunk Cloud in the Log Streaming API.

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.

OAuth 2.0 Push Authorization Requests

Okta authorization servers now support push authorization requests in the /par endpoint to enhance OAuth security. This feature allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server through a direct /par request and, in return, a request URI that is used to reference the payload data is provided by the authorization server. The request URI is then used in a subsequent /authorize request to reference the initial authorization payload. See the /par OAuth 2.0 API endpoint.

Signed request support for generic OIDC IdP is GA in Preview

When customers integrate Okta with an OpenID Connect-based Identity Provider, Okta asks the IdP to authenticate the user with request elements that are passed as query parameters in the URL. The new Signed Request Object allows customers to send these parameters encoded in a JWT instead, improving security on the authorization request sent to the OpenID Connect provider or authorization server.

Client secret rotation and key management is GA in Preview

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.

Okta Org2Org integration supporting Okta API access using an OAuth 2.0 client is GA in Preview

The Okta Org2Org integration enables you to push and match both users and groups from one Okta org to another. Previously, this 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.

Bug fixed in 2022.04.0

Performing a POST request on the /apps/{applicationId} endpoint didn't update the secret if the org had the Client Credentials Management feature enabled. (OKTA-482341)

March

Weekly release 2022.03.3

Change Expected in Preview Orgs
Bug fixed in 2022.03.3 March 23, 2022

Bug fixed in 2022.03.3

The auth_time claim wasn't defined as a reserved system claim. (OKTA-478924)

Weekly release 2022.03.2

Change Expected in Preview Orgs
Bugs fixed in 2022.03.2 March 16, 2022

Bugs fixed in 2022.03.2

  • An error was returned when a valid update request was made for the device_sso or online_access system scopes. (OKTA-417477)

  • Sending an error object in the response message of an Inline Registration Hook resulted in an error message that included domain details and didn’t target attributes. (OKTA-473152)

Weekly release 2022.03.1

Change Expected in Preview Orgs
Bugs fixed in 2022.03.1 March 09, 2022

Bugs fixed in 2022.03.1

  • Performing a GET request on the /policies/ endpoint sometimes returned a page with the wrong number of items. (OKTA-455164)
  • When the List email templates or the List email customizations operations were performed on the /brands/ endpoint, the base address in the link response header contained the -admin string instead of the requested base address. (OKTA-465356)
  • When modifying the custom email activation template, an admin could save the template without either of the required verificationLink or verificationToken elements. (OKTA-472895)
  • When modifying the custom email challenge template, an admin could save the template without either of the required emailAuthenticationLink or verificationToken elements. (OKTA-472928)

Monthly release 2022.03.0

Change Expected in Preview Orgs
Authentication timestamp is added as an access token claim March 2, 2022
Custom Administrator Roles is GA in Production February 3, 2022
Email Address Bounces API is EA in Preview March 2, 2022
Shareable Authentication Policies March 2, 2022
Signed request support for generic OIDC IdP is EA in Preview March 2, 2022
Bugs fixed in 2022.03.0 March 2, 2022

Authentication timestamp is added as an access token claim

The user-authenticated epoch timestamp is provided as the auth_time claim in the access token.

Custom Administrator Roles is GA in Production

The Okta Custom Administrator Roles API provides operations that you can use to create customized roles and assign them to a user or a group.

Email Address Bounces API is EA in Preview

Okta admins can now control the bounced email address list through the Email Address Bounces API. When Okta-sent email addresses are blocked from an email service (the bounced email list), admins can use this API to create a list of blocked email addresses to be removed from the email service.

Shareable Authentication Policies

Admins can now manage authentication policies using a centralized view. While authentication policies allowed admins the ability to make application access decisions using user, device, and other contextual information, managing these policies across hundreds of applications became challenging and error-prone.

On the new Authentication Policies page, admins can create new policies, apply those policies to multiple applications, and assess what application access decisions are impacted by each policy.

Two policy name changes are included in this release: app sign-on policy is renamed authentication policy, and Okta sign-on policy is renamed Global Session Policy. See Configure a Global Session Policy and authentication policies and Authentication policies (opens new window).

Signed request support for generic OIDC IdP is EA in Preview

When customers integrate Okta with an OpenID Connect-based Identity Provider, Okta asks the IdP to authenticate the user with request elements that are passed as query parameters in the URL. The new signed request object allows customers to send these parameters encoded in a JWT instead, improving security on the authorization request sent to the OpenID Connect provider or authorization server.

Bugs fixed in 2022.03.0

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

  • The OAuth 2.0 /token and /authorize endpoints accepted requests that included the resource parameter. (OKTA-476549)

February

Weekly release 2022.02.2

Change Expected in Preview Orgs
Okta Org2Org integration now supports Okta API access using an OAuth 2.0 client February 16, 2022

Okta Org2Org integration now supports Okta API access using an OAuth 2.0 client

The Okta Org2Org integration enables you to push and match both users and groups from one Okta org to another. Previously, this 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.

Weekly release 2022.02.1

Change Expected in Preview Orgs
API token ID added to System Log event types February 9, 2022
Bug fixed in 2022.02.1 February 9, 2022

API token ID added to System Log event types

API requests that include an API token and return a System Log event now include the API token in the event payload. The token identifier appears in the System Log API transaction.details.requestApiTokenId field and in the Event > System > Transaction > Detail > RequestApiTokenId node in the Admin Console System Log.

To view an example of this new event detail, create a user by API and view the associated event (user.lifecycle.create).

Bug fixed in 2022.02.1

The OAuth token endpoint didn’t reject requests that included a code_verifier parameter if the authorization call was issued without the PKCE code_challenge parameter. (OKTA-461970)

Monthly release 2022.02.0

Change Expected in Preview Orgs
Custom Administrator Roles is GA in Preview February 3, 2022
Client secret rotation and key management is EA February 3, 2022
Group role assignment improvement February 3, 2022
Custom Domains with Okta-Managed Certificates is GA in Production February 3, 2022
Bug fixed in 2022.02.0 February 3, 2022

Custom Administrator Roles is GA in Preview

The Okta Custom Administrator Roles API provides operations that you can use to create customized roles and assign them to a user or a group.

Client secret rotation and key management is EA

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.

Group role assignment improvement

Assigning a role to a group through the Administrator Roles API has been enhanced by retaining the existing role assignment ID where possible.

Custom Domains with Okta-Managed Certificates is GA in Production

When you customize an Okta URL domain, your Okta-hosted pages are branded with your own URL. Okta-Managed Certificates auto renew through a Let's Encrypt integration, a free certificate authority. Since Okta handles certificate renewals, this reduces customer developer maintenance costs and the high risk of a site outage when certificates expire.

Bug fixed in 2022.02.0

In the Custom Administrator Roles API, some public DELETE requests returned a different response code than their contract. (OKTA-456896)

January

Weekly release 2022.01.2

Change Expected in Preview Orgs
Device information in the OAuth 2.0 Interaction Code flow January 26, 2022
Fewer digits revealed for shorter phone numbers January 26, 2022
Bugs fixed in 2022.01.2 January 26, 2022

Device information in the OAuth 2.0 Interaction Code flow

Confidential clients can now specify device information using the X-Device-Token header during the OAuth 2.0 Interaction Code flow.

Fewer digits revealed for shorter phone numbers

The masking algorithm now reveals fewer digits in API responses for shorter profile phone numbers.

Bugs fixed in 2022.01.2

  • Administrators were able to access and modify internal policies. (OKTA-455506)

  • When an invalid client assertion type was provided during a Client Credentials grant type flow, the error response code was 401 instead of 400. (OKTA-456503)

  • When the Create a new Binding or the Add more Members to a Binding operation was performed on the /iam/resource-sets endpoint, and included all users or all groups in the request, the request didn't fail as expected. (OKTA-459994)

  • When the Get all policies operation was performed on the /policies endpoint, unused Radius policies were returned. (OKTA-460965)

Weekly release 2022.01.1

Change Expected in Preview Orgs
Bugs fixed in 2022.01.1 January 13, 2022

Bugs fixed in 2022.01.1

  • If the Create a Scope endpoint received multiple requests at or near the same time, duplicate Scopes could be created. (OKTA-442533)

  • When the Update resource set endpoint was called, the resourceSetId parameter was required in the body of the request. (OKTA-445144)

  • When the Upload Theme background image endpoint was called, the image was converted to PNG format. (OKTA-458260)

  • When the List events operation was performed on the /logs endpoint, some system logs showed the incorrect status for debug behaviors if there was missing data that prevented behavior evaluation. (OKTA-455372)

Monthly release 2022.01.0

Change Expected in Preview Orgs
Dynamic Issuer Mode is GA in Production December 8, 2021
Custom domains with Okta-managed certificates is GA in Production December 8, 2021
New permissions for custom admin roles January 6, 2022
Self-service password reset with User API January 6, 2022

Dynamic Issuer Mode is GA in Production

An authorization server's issuer URL can be used to validate whether tokens are issued by the correct authorization server. You can configure the issuer URL to be either the Okta subdomain (such as company.okta.com) or a custom domain (such as sso.company.com). See Property details.

When there are applications that use Okta's subdomain and other applications that use the custom domain, the issuer validation breaks because the value is hard-coded to one domain or the other.

With Dynamic Issuer Mode, the issuer value in minted tokens is dynamically updated based on the URL that is used to initiate the original authorize request. See Client application settings.

Custom domains with Okta-managed certificates is GA in Production

When you customize an Okta URL domain, your Okta-hosted pages are branded with your own URL. Okta-managed certificates automatically renew through a Let’s Encrypt integration, a free certificate authority. Okta-managed certificate renewals lower customer developer maintenance costs and reduce the high risk of a site outage when certificates expire.

New permissions for custom admin roles

The Administrator Roles API includes new app permissions for custom admin roles to run end-to-end imports. See About role permissions (opens new window).

Self-service password reset with User API

Client applications that use the Users API /users/{$userId}/credentials/forgot_password to implement the self-service account recovery (opens new window) flow can now use this API call with password policies configured with the Any enrolled authenticator used for MFA/SSO additional verification option.