March 2020

2020.03.0: Monthly Preview release began deployment on March 4

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

Generally Available Features

New Features

Changes to admin permissions

Super admins can no longer edit their own role assignment. The Edit and Delete actions are removed from their profile row on the Administrators page. See Super admin role.

Pagination is now available when listing Authorization Servers

Pagination is now available for lists of authorization servers. See API Access Management.

Custom Email events added to the System Log

Updates to custom email templates are now tracked in the System Log.

Email verification added as optional enrollment factor

If admins configure email verification as an optional MFA factor, end usersEnd users are people in your org without administrative control. They can authenticate into apps from the icons on their My Applications home page, but they are provisioned, deprovisioned, assigned, and managed by admins. can select email as a factor during MFA enrollment. To complete enrollment, end users enter the code sent to their primary email address. The verification UI is redesigned.

Sign-in attempt behavior evaluation is logged when there is no client information

Sign-in attempt behavior evaluation is logged in the debugContext object of the user.session.start and policy.evaluate.sign_on events even when clientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. information is missing for all behaviors.

Jira Authenticator, version 3.1.3

This release contains a bug fix for SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IdP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on an app, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. SPAn acronym for service provider. Generally, an SP is a company, usually providing organizations with communications, storage, processing, and a host of other services. Within Okta, it is any website that accepts SAML responses as a way of signing in users, and has the ability to redirect a user to an IdP (e.g., Okta) to begin the authentication process.-initiated flows, to ensure that all supported URLs redirect to Okta.  See Okta Jira Authenticator Version History.

Email as a factor for MFA

Email is now an accepted factor for multifactor authentication for convenience and to expedite migration from legacy identity platforms. After setup, your end users receive a code in an email message to use during Okta sign in. For details on setting up this factor, seeMultifactor Authentication .

Third-party admin role

Some organizations have a business need to to set up administrator roles in Okta for individuals who perform adminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. functions but are not direct employees of the organization. By introducing the concept of a third-party admin in Okta, we are able to treat these admins differently than the typical Okta admins who interact directly with the Okta Admin Console. See Third-Party admins.

OAuth for Okta

With OAuth for Okta, you are able to interact with Okta APIs using scoped OAuth 2.0 access tokens. Each access token enables the bearer to perform specific actions on specific Okta endpoints, with that ability controlled by scopes that the access token contains. See OAuth for Okta guide.

Note that at this time, OAuth for Okta works only with the APIs listed in the Scopes & supported endpoints section of our developer docs. We are actively working towards supporting additional APIs. Our goal is to cover all Okta public API endpoints.

Provision out of sync users

If you enable provisioning for an appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. that already has users assigned to it, Okta can sync these users so they now have provisioning capabilities. See Provisioning and Deprovisioning.

People page improvements

The People page has been improved so the people list can be filtered by user type. See Work with custom user types in Universal Directory.

Generally Available Enhancements

Salesforce integration supports pushing null values

The Salesforce integration supports pushing null values to user profile updates. To enable this functionality, select the Allow Pushing Null Values option on the Provisioning tab.

Veeva Vault integration update

The Veeva Vault integration has a new check box on the Provisioning tab that allows admins to choose whether to use Email instead of Username.

Spotlight search bar changes

The spotlight search bar is no longer visible to Report Admins because they do not have search permissions.

Accessibility enhancement for Okta Sign-in Widget

The Username and Password form fields on the Sign-In page now include the aria-required property. This property is not visible to end users, but indicates to screen readers that these fields are required.

Profile Editor improvements

The Profile Editor page has been improved to simplify navigation and clarify functionality.

Early Access Features

New Features

Okta Verify support for risk-based authentication

Okta Verify with Push now supports risk-based authentication. With this feature, admins can assess the level of risk when an end user signs in to their orgThe Okta container that represents a real-world organization. and attempts to authenticate with Okta Verify. See Enable risk-based authentication for Okta Verify with Push.

New Group Membership Admin role

The new Group Membership Admin role grants permission to view all users in an org and manage the membership of groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups.. See Group Membership Admin role.

App-level safeguard

To guard against an unusual number of app un-assignments during user import, the admin can set the safeguard to org-level, app-level, or both. See Import safeguards.


General Fixes


App admins were able to modify all profiles in the Profile Editor even when the admin was limited to only administer certain apps.


The Okta Admin Console displayed options to delete or deactivate app instances that can't be deleted or deactivated.


When the App Catalog feature was enabled, app admins with required permissions received a blank page when they clicked the Add Application button.


In some cases, a SAML assertion incorrectly included extra Attribute Statements. Note that this fix currently only applies to Preview orgs.

App Integration Fixes

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

  • Blanchard Exchange (OKTA-278301)

  • ConnectWise Automate (OKTA-278300)

  • Playbook (OKTA-279423)


New Integrations

New SCIM Integration Applications

The following partner-built provisioningThis term is obsolete. See "Okta Verified". integration apps are now Generally Available in the OINAn acronym for the Okta Integration Network. The OIN is comprised of thousands of public, pre-integrated business and consumer applications. As an on-demand service, OIN integrations are continuously validated, always up to date, and constantly growing both in number and capability. Okta performs a single integration with an ISV or SP, providing thousands of end users with point-and-click customization for their orgs. as partner-built:

SAML for the following Okta Verified applications

  • Halogen (OKTA-280008)

  • OneDesk (OKTA-276015)

  • Parabol (OKTA-278665)

SWA for the following Okta Verified application

  • Altair Eyewear (OKTA-277992)

Weekly Updates


Profile Mastering and Push can be enabled together

Admins can enable both Profile MasterA profile master is an application (usually a directory service such as Active Directory, or human capital management system such as Workday) that acts as a source of truth for user profile attributes. A user can only be mastered by a single application or directory at any one time. For more details, see the Profile Master page. When users are mastered by attribute, we call this attribute-level mastery (ALM). ALM delivers finer grain control over how profiles are mastered by allowing admins to specify different profile masters for individual attributes. Profile mastering only applies to Okta user profiles, not app user profiles. For more details, see Attribute Level Mastering. and Push for an app. This allows all Okta-to-App mappings to push, regardless of whether Active DirectoryActive Directory (AD) is a directory service that Microsoft developed for the Windows domain networks. It is included in most Windows Server operating systems as a set of processes and services. Initially, Active Directory was only in charge of centralized domain management. is the Profile Master.


Early Access features, auto-enroll

You can now opt to auto-enroll in all Early Access features, instead of having to enable them as they become available. For more information, see Manage Early Access and Beta features .

Connecting Apps to Okta using the LDAP Interface

The LDAP Interface allows you to authenticate legacy LDAP apps to Universal Directory in the cloud. With the LDAP Interface, authentication is done directly against Okta via LDAP, without the need for an on-premise LDAP server. In addition, the LDAP interface supports other LDAP functions like search. For details, see Using the LDAP Interface.

Identity Provider Discovery

Using Identity Provider Discovery and routing rules, Okta directs users to different identity providers based on certain criteria. These criteria include location, device, the app being accessed, the user's domain, and specific user attributes. For more information see Identity Provider Discovery.