Early Access

We have removed UI elements supporting account link and provisioning Callouts when configuring social authentication.

Note that Callouts are still supported via the APIs. See Identity Provider API reference documentation for more details.

This version contains a fix for log messages that displayed an incorrect response code for requests that were successful. For version history information, see Okta RADIUS Server Agent Version History.

This release of the On-Prem MFA agent uses an updated JRE (version 1.8.182). For version history, see Okta On-Prem MFA Agent Version History.

This release contains an updated JRE (version 1.8.182). For version history information, see Okta RADIUS Server Agent Version History.

Okta has added a new setting to enable FIPS-mode encryption for all security operations using the FIPS 140-2 standards. For more information about this feature, refer to Using Okta Verify. Screenshot:

Okta end users need to reverify their password if they want to update their personal information in Okta five minutes after a successful login. For more information about letting end users manage their personal information in Okta, see Configure whether user passwords and personal information are managed by Okta or externally.

This release includes a security fix and memory performance improvements when streaming data. For agent version history, see Okta Active Directory Agent Version History.

This release provides a security fix and internal fixes. For agent version history, see Okta SSO IWA Web App Agent Version History.

For Desktop Device Trust Authentication flows, the System Log now reports the CredentialType as CERTIFICATE. Screenshot:

MFA for Admins allows Super admins to enable mandatory multifactor authentication for all administrators accessing admin functionality. This feature is currently available for new orgs in Preview, for all others it remains EA. For details see Authentication.

This feature enables you to customize where Okta will redirect your users when they visit your org URL directly and the specific app they are attempting to use is unknown. For more details, see Redirect end users when the target app is unknown.

The System Log now reports when Windows Device Trust certificates are revoked during certificate renewal (pki.cert.revoke).Screenshot

This release contains the following fixes:

• Changes to the debug logging levels were not captured
• Okta authentication with JIT failed when the user ID contained ASCII extended characters
• Agent did not recognize pwd expired error for ODSEE server

For version history, see Okta Java LDAP agent version history.

Admins can generate a report of proxy IP addresses that have been used by end users who have signed in to Okta. This feature is Generally Available for new orgs that have the Geolocation for Network Zones feature and is available with either of the following Early Access Features:

• Dynamic Zones
• Security Behavior Detection

For more information on Proxy IP Usage Reports, see Reports.

Windows and macOS Device Trust certificate issuance and renewal failures are now reported in the System Log. Screenshot:

Windows Device Trust certificate renewals are now reported in the System Log by event type pki.cert.renew. This new event type allows you to distinguish certificate renewal events from certificate issue events (pki.cert.issue). Screenshot

In Okta Plug-in version 5.23.0 for IE, the popover now scales properly to correspond to the window's zoom level. For version history, see Okta Plugin Version History.

This release provides the following:

• Organizations that have complex proxy configuration rules defined in a proxy auto-config (PAC) file can now specify the PAC location instead of the server address. For details, see Enforce Okta Device Trust for managed Windows computers.
• Prevents the Device Trust certificate installation prompt from appearing to end users using 32-bit versions of Internet Explorer.

For version history, see Device Trust for Windows Desktop Registration Task Version History.

This EA version updates the embedded JRE to JRE 1.8 version 181. For history, see On Premises Provisioning Agent and SDK Version History.

When configuring RADIUS applications, the Single line MFA prompt is the default in the Advanced RADIUS Settings section for new RADIUS and VPN app instances. This option controls whether all MFA prompts are displayed on a single line. For more information, see Configuring RADIUS applications in Okta.

You can configure RADIUS applications to show prompts on a single line with no line breaks in MFA prompts. Screenshot

• The Okta plugin version 5.22.1 for the Chrome browser is GA. This version is functionally equivalent to version 5.19.0.
• The Okta plugin for Edge, Firefox, IE, and Safari browsers is updated to version 5.22.0. This version provides support for the End-User Plugin Settings (an Early Access feature; to enable it, contact Okta Support). Version 5.22.0 is GA for Edge browsers and EA for Firefox, IE, and Safari browsers.  For history, see Browser Plugin Version History.

Okta has added an Update Now button that allows admins to update a username from the app’s Sign On tab. For more details, see Overriding the app username.

Admins can send themselves a test email to see how their custom email templates will look and function. This allows them to validate macro attributes and translations in the customized template and to see how the template will render in different email environments. This eliminates the need to create a real end-to-end workflow to test customization. The test email will be sent to the primary email address of the admin initiating the test email. For more information, see Email Options. Screenshot

Improved IdP lookup when Multiple PIV IdPs are enabled by using the 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. certificate Issuer to identify the signing certificate, if the Authority Key Identifier property cannot be used. For more details see Identity Providers.

This release provides functionality to restrict the network interface on which RADIUS request can be received.

For version history see Radius Agent version history.

Our Multiple Certificate Chain Support for PIV Auth feature allows you to leverage multiple Smart Card/PIV Card IdPs, each with different certificate chains, to allow access to a single Okta org. The correct IdP will be automatically selected based on matching the user's chosen certificate to a configured certificate chain.

For more details see Identity Providers.

A new security feature provides admins with an option to require user data storage in the Android hardware-backed keystore. Enabling this feature offers additional security based on the Federal Identity, Credential, and Access Management architecture. Screenshot:

For more information, see Using Okta Verify.

Okta has removed the delete user actions from the list of Early Access deprovisioning options. Administrators continue to have granularity when deactivating/unassigning users from Microsoft Office 365.

The Box integration is enabled for Universal Directory and is enhanced by the following additional properties in the User Profile:

• firstName
• lastName
• timezone
• language
• space_amount (RO)
• max_upload_size (RO)
• job_title
• phone
• address
• avatar_url (RO)
• groups
• space_used (RO)

See the Box Provisioning Guide for more information.

As a result of reports optimization efforts, our Applications Access Audit reports (Early Access) are now by default ordered by appUserId rather than lastName. For more information about these reports, see Applications Access Audit report.

Agentless desktop SSO eliminates the need to deploy IWA agents across Active Directory domains to enable DSSO. This reduces maintenance overhead and also removes the burden of worrying about High Availability as Okta handles the Kerberos validation. For details, see Configuring Agentless SSO.

In Self Service Registration settings you can now select an option to add a Sign Up link in your Okta hosted Sign-In page. This eliminates the need to configure the link via JavaScript in the Custom Sign In page editor. For more information, see Okta Self-Service Registration. Screenshot

Improved configuration of the applicable applications in the IdP policy routing rule in the Identity Provider Discovery EA feature. The application selection is enhanced to show app logos to differentiate between apps and app instances more clearly. For more information see Identity Provider Discovery. Screenshot:

This feature allows dynamic mapping of multiple accounts/roles within AWS by using group assignments from Okta. By using the App Filter and Group Filter, we can specify which account and role the user will use to login into AWS. For more information see the Okta AWS Multi-Account Configuration Guide. Screenshot:

The enrollment flow for 3rd-party iOS Device Trust is improved for end users who are not enrolled in an MDM solution and do not have Okta Mobile installed. In cases where Okta cannot automatically redirect these end users to the admin-provided enrollment link configured in Okta, end users can now copy the link to the clipboard and paste it into Safari. Screenshot:

For more about 3rd-party iOS Device Trust, see Configure Okta Device Trust for Native Apps and Safari on MDM-managed iOS devices.

Workday users can be deactivated based on the time zone of their location.

For more information about our Workday integration see our Workday Provisioning Guide.

We have enhanced 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. app catalog search, extending search capabilities to include partial matches and more attributes of the application metadata.

Example without enhanced search:

Example with enhanced search: 

End users can now toggle visibility of their password on the Okta Sign-In page, allowing end users to check their password before they click Sign In. Note that passwords are visible for 30 seconds and then hidden automatically. For more information about passwords in Okta, see Authentication. Screenshot:

The Okta ADFS (Active Directory Federaton Services) Plugin version 1.5.9 is available. This version contains two features:

• UI option and silent command line option to register the plugin during install. Screenshot:

  

• The client IP address is forwarded during a request from the ADFS plugin to Okta.

For version history, see Okta ADFS Plugin Version History.

Okta Self Service Registration allows end users to self-register into your custom app or the Okta Homepage. Once enabled, a Sign up link appears in the Okta Sign-In widget. This link takes users to a new Create Account registration form based on a customized registration policy. For details, see Self Service Registration. Screenshot:

You can customize the text and the look and feel of the Okta-hosted sign-in page using form controls and an embedded HTML editor. When used together with custom URL domain (required) and custom Okta-hosted error page, this feature offers a fully customized end user sign-in experience hosted by Okta. For details, see Configure a custom Okta-hosted sign-in page. Screenshot:

You can customize the text and the look and feel of error pages using an embedded HTML editor. When used together with custom URL domain (required) and custom Okta-hosted sign-in page, this feature offers a fully customized error page. For details, see Configure a custom error page. Screenshot:

The enrollment flow for 3rd-party iOS Device Trust is improved for unenrolled end users accessing certain native clients such as Outlook. End users can now copy a link to their organization's enrollment instructions and paste it into Safari. For details about this Device Trust solution, see Configure Okta Device Trust for Native Apps and Safari on MDM-managed iOS devices. Screenshot:

This feature expands on existing behavior detection feature for user logins. Close successive user login attempts that are far apart geographically are detected and flagged as suspicious behavior. For more information, see Security Behavior Detection.

Okta Office 365 Silent Activation allows for a seamless experience for your Microsoft Office 365 end users accessing Office 2016. Using Okta as an identity provider, this option enables silent activation of Office 2016 on shared workstation or VDI environments. Once your end users have logged into a domain-joined Windows machine, no further activation steps are required. For more details, see Office 365 Silent Activation.

This feature provides support for Okta-mastered users to move across Organizational Units (OUs) when the group that provisions the user to AD changes. As part of this update, the People tab within each AD instance has been renamed to Assignments. For more details, see Enable Okta-mastered user OU changes. Screenshot:

This release provides performance and security enhancements. To obtain them, contact Okta Support. For version history, see Browser Plugin Version History.

Are you tired of end users utilizing "Jaibroken" or "Rooted" devices to access sensitive apps? Admins will be pleased to hear that admins can now deny enrollment to compromised devices and/or any specific OS versions. Compliant users can enroll new devices or retain their current enrollments. See Restrictions based on Device Status and Operating System. Screenshot:

A popup that informs users when a policy allows access without MFA, is removed.

This release includes the following: 

• The context menu is removed from the Okta sign-in widget for RDP connections to avoid opening an Explorer file dialog.
• There are two additional options: RDP only and filter credential provider. For more information, see Okta Windows Credential Provider.

Screenshot:

The Okta System Log records system events related to your organization in order to provide an audit trail that can be used to understand platform activity and to diagnose problems.

The Okta System Log API provides near real-time read-only access to your organization’s system log and is the programmatic counterpart of the System Log user interface.

Often the terms “event” and “log event” are used interchangeably. In the context of this API, an “event” is an occurrence of interest within the system and “log” or “log event” is the recorded fact.

Notes:

The System Log API contains much more structured data than the Events API.

The System Log API supports additional SCIM filters and the q query parameter, because of the presence of more structured data than the Events API.

Okta supports salted SHA256 algorithms for password import.

A consent represents a user’s explicit permission to allow an application to access resources protected by scopes. As part of an OAuth 2.0 or OpenID Connect authentication flow, you can prompt the user with a popup or window to approve your app's access to specified resources.

Consent grants are different from tokens because a consent can outlast a token, and there can be multiple tokens with varying sets of scopes derived from a single consent. When an application comes back and needs to get a new access token, it may not need to prompt the user for consent if they have already consented to the specified scopes. Consent grants remain valid until the user manually revokes them, or until the user, application, authorization server or scope is deactivated or deleted. Screenshot:

See User Consent for OAuth 2.0 and OpenID Connect Flows

Okta Device Trust for Native Apps and Safari on OMMAn acronym for Okta Mobility Management. OMM enables you to manage your users' mobile devices, applications, and data. Your users enroll in the service and can then download and use managed apps from the Apps Store. Managed apps are typically work-related, such as Box or Expensify. As an administrator, you can remove managed apps and associated data from users' devices at any time. You can configure policies, such as data sharing controls, on any of your managed apps. See Configuring Okta Mobility Management for more information. managed iOS devices now supports use of the Not trusted option in Sign-On policy rules. This allows mobile admins to do the following:

• Configure a Not Trusted + MFA rule so that users with untrusted iOS devices must MFA in order to access protected resources.
• Configure a Not Trusted + Deny rule so that users with untrusted iOS devices are redirected to OMM enrollment in order to access protected resources.

This update requires Okta Mobile 5.14 for iOS, available in the App Store. For more information, see Configure Okta Device Trust for Native Apps and Safari on OMM managed iOS devices.

The Okta On-Prem MFA Agent Version 1.3.6 adds additional NAS-IP identifiers, including the NAS-IP-Address field, to find client configurations in server policies. For version information, see Okta On-Prem MFA Agent Version History.

The Okta Windows Credential Provider prompts users for MFA when signing in to supported Windows servers with an RDP client. It supports all Okta-supported MFA factors except Windows Hello and U2F tokens. For details and setup instructions, see Okta Windows Credential Provider.

Okta Device Trust for MDM managed iOS devices allows you to prevent unmanaged iOS devices from accessing enterprise services through browsers and native applications. Screenshot:

Note: This feature requires Okta Mobile 5.12 for iOS (or later), available in the App Store beginning February 1st.

For details, see Configure Okta Device Trust for Native Apps and Safari on MDM managed devices.

To provide additional security without overburdening your end users, you can configure a Sign On policy for your organization to require additional authentication for behaviors defined as higher risk based on variance from individual users' prior sign ins. Admins can configure the system so that individual end users are only prompted for an additional MFA factor when there is a change in behavior that the admin defines. For more information, see Security Behavior Detection. Screenshot:

Okta now supports incremental imports for the Workday app.

Incremental imports improve performance by only importing users that were created, updated, or deleted since your last import.

Admins can choose from a list of custom attributes to use for matching when using a personal identity verification (PIV) card. Note: This is an enhancement to our support for PIV smart card feature (EA), for more information, see Add a PIV Card.

You can define dynamic network zones that match both proxy and location specifications. For more information, see Network Zones.

Admins can restrict the use of commonly used passwords through the group password policy. For more information, see Configuring an Organization-wide Password Policy.

Admins can configure a single personal identity verification (PIV) card as an identity provider that matches tje username or email. This allows users to authenticate using certificates or PIV hardware. For more information, see Identity Providers.

The Add Notes screen has design improvements to improve the workflow. For details, see Add Notes to an App (an Early Access feature).

The Okta Windows Credential Provider prompts users for MFA when signing in to supported Windows servers with an RDP client. It supports all Okta-supported MFA factors except Windows Hello and U2F tokens. For details and setup instructions, see Okta Windows Credential Provider.

You can now revoke an end user's certificate(s) for Okta Device Trust for managed Windows computers through their Applications tab. This is recommended if an end user's Windows computer is lost or stolen. For details, see Revoke Device Trust certificates from the Okta Certificate Authority. Screenshot

Okta Mobile user and device authentication events for OMM Device Trust for managed iOS devices are now written to the System Log.

The JIRA and Confluence apps now make use of a unique identifier during Atlassian API calls for profile updates instead of username. This allows users to be renamed.

Along with custom SAML Wizard apps, Federation Broker Mode now allows for OIDC apps. For details about this feature, see Federation Broker Mode.

Okta now supports Password Push for LDAP. This allows each user's LDAP password to be synced to their Okta password. Any subsequent password changes users make are pushed to their user profile in LDAP. In addition to simplifying password management for orgs using LDAP, organizations using both Active Directory (AD) and LDAP can now synchronize their user passwords from AD through Okta to LDAP. For details, see the Provisioning section in Install and Configure the Okta Java LDAP Agent.

We are transitioning the Profile Sync provisioning type for Microsoft Office 365 over to the Microsoft Graph API. While this is mostly a transparent change to Okta customers, it will enable a wealth of new attribute mappings for Office 365. You can now go beyond the base set of attributes to map a new set of custom attributes that are present in Microsoft’s Graph. For more information, see the Office 365 Deployment Guide. Screenshot

OMM Device Trust for managed iOS devices allows you to prevent unmanaged iOS devices from accessing enterprise services through browsers and native applications. For details, see Configure OMM Device Trust for managed iOS devices.

You can compare user assignments in Okta to user accounts in a specified app and list the discrepancies. Once corrected, you will only have to look in one place to see who has access and what type of access for all the applications that you manage. For details, see Rogue Accounts report.

The Okta plugin for the IE browser has been updated to version 5.13.0. This release provides performance and security enhancements. For version history, see Browser Plugin Version History.

The security question in the password recovery flow is now an optional factor. This feature requires the use of a group password policy. For more information, see Account Recovery.  Screenshot

The new Federation Broker Mode allows Okta SSO without the need to pre-assign apps to specific users. Access is managed only by sign-on policy and the authorization rules of each app. This mode can improve import performance and can be helpful for larger-scale orgs that manage many users and apps. For details, see Federation Broker Mode.

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, see Factor Types.

With the addition of the following Provisioning Features, Okta's LDAP integrations now closely match the functionality already available to Okta Active Directory (AD) integrations Screenshot

• Create Users

• Update and deactivate LDAP accounts

• DN customization

• Profile Masters

For more information, see Provisioning Features.

During inbound SAML authentication, you can configure the JIT settings for a SAML identity provider (IdP) to unsuspend Okta users. For more information, see the Identity Providers API.

Okta Device Trust for Microsoft Office 365 Exchange ActiveSync for iOS devices lets you:

• Configure the iOS mail app to use certificates instead of passwords to allow OMM-enrolled users to authenticate to Microsoft Office 365 Exchange ActiveSync.

• Configure the Microsoft Office 365 client access policy to prevent unmanaged devices from accessing Microsoft Office 365 Exchange ActiveSync.

For details, see Configure Okta Device Trust for Microsoft Office 365 Exchange ActiveSync for iOS devices. Screenshot

Okta's Office 365 Exchange ActiveSync certificate-based authentication (CBA) for iOS devices allows users enrolled in Okta Mobility Management (OMM) to authenticate to iOS native apps without entering their credentials. For details, see Configure Office 365 EAS certificate-based authentication for iOS devices. Screenshot

This feature automatically provisions a user in Okta upon successful login through a Office365 thick client if the user is AD-mastered and is a member of an AD-mastered group in Okta being assigned a valid Office 365 application instance.

We have updated the Jira authenticator to support the following events:

• fireLoginEvent
• fireUserAuthenticatedEvent
• userAuthenticatedEvent

This enhancement adds support for Just In Time provisioning of default group memberships when users log in. For details, see the Okta Jira Authenticator 3.x Configuration Guide

We strongly recommend that you download and upgrade the latest SAML toolkit and the necessary Jira or Confluence authenticators. You can access all of these tools from the Okta Downloads page (Settings > Downloads).

We have added new reports to our Reports page.

An App Access Audit section has the following two reports:

• The Current Assignments report contains data about how an application is being used over a specified time range.
• The Recent Unassignments report shows which users were unassigned from an app for a specified period.

We’ve enhanced our System Log to take advantage of our new Network Zones feature. Admins can now hover over an IP address that's part of an event and navigate through the series of menus to add that IP address to either the gateway or proxy list of IP addresses:

We have enhanced the landing URL for the Office 365 CRM chiclet; after the end user signs in and authenticates themselves into Dynamics 365, they are now able to see all of their CRM instances.

• We have enhanced user group synchronization for Microsoft Office 365 instances that are configured with Universal Sync to ensure that newly provisioned AD-mastered O365 users are synchronized as members of AD-mastered Groups in O365 correctly.

We now support reactivation of users in the following cases:

• During Just in Time provisioning (JIT), if a user is reactivated in a master app (for example, LDAP, AD), then the user is reactivated in Okta.
• During imports, if a user is reactivated in a master app (for example, LDAP, AD), then the user is reactivated in Okta.

The Access Request Workflow feature is a complete, multi-step approval workflow through which end users can request access to apps. Admins can select approvers that have the ability to grant access to self-service applications. Access Request Workflow allows you to appoint group and individual approvers, create customized notifications, and add comments, notes, and timeout rules. You perform all setup from the Okta Admin Dashboard and no programming or configuration files are required. For more information, see Access Request Workflow.Screenshot

Note: This Early Access (EA) feature requires either the Enterprise Plus or Provisioning Product editions. To enable it, contact Okta Support.