Okta Office 365 Application-Based Authentication Update Frequently Asked Questions

Updating the Microsoft Office 365 integration to support Application-Based Authentication (ABA) for Okta provisioning raises questions about the impact on Single Sign-On (SSO), provisioning interruptions, and Push Group configurations. The update only affects the provisioning connection, leaving SSO uninterrupted, and administrators can safely perform the update during business hours without affecting existing Push Group mappings. Administrators require clarification on the impact of this update on active users, potential transient errors, and the September 30, 2026, provisioning risk.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Microsoft Office 365
• Provisioning
• Application-Based Authentication (ABA)

Does the Application-Based Authentication update disrupt Single Sign-On logins?

Application-Based Authentication (ABA) only replaces the credential model behind the provisioning integration for Microsoft Office 365. The update moves the integration from the legacy service account model to an Application Registration and Service Principal model. Administrators perform the re-authentication steps entirely within the provisioning settings of the application. This configuration surface is distinct from the sign-on settings, which hold the Security Assertion Markup Language (SAML) or WS-Federation trust relationship that active users authenticate against. Re-authentication does not alter that trust relationship, ensuring Single Sign-On (SSO) logins continue uninterrupted.

What are the provisioning interruption and timing expectations?

Administrators can safely perform the update during business hours and must plan for the following requirements and potential transient errors.

• Administrators require a Microsoft Global Administrator credential with Multi-Factor Authentication (MFA) enabled to complete the consent grant. An Okta Application Administrator role is also necessary. Schedule the change when the administrator possessing these credentials is available.
• Administrators might encounter an error notification stating the following message:

The client secret for the ADSync app is invalid or has been removed. Please re-authenticate to remediate the provisioning.

This known condition occurs due to potential replication latencies on the Microsoft platform.

Resolve the transient error by navigating to the Microsoft Office 365 application in the Okta Admin Console and saving the provisioning integration settings to re-push the application instance.

1. 1. Navigate to the Okta Admin Console.
   2. Go to Applications and select the Microsoft Office 365 application.
   3. Select the Provisioning tab and choose Integration.
   4. Select Edit and then select Save to re-push the application instance, or retry the push from the Tasks page for the impacted instance.

How does the update affect Push Groups and license assignments?

Push Groups execute through the same underlying provisioning connection that Application-Based Authentication re-authenticates. Group Push operates on the same provisioning integration rather than a separate authentication path.

• Re-authentication does not reset or unlink existing Push Group mappings or license assignments. These configurations exist within Okta and remain independent of the underlying credential model executing the synchronization.
• Push Groups carry the same September 30, 2026, risk as standard user provisioning. Because Group Push-driven license assignment is a provisioning operation on this integration, the synchronization halts alongside regular synchronization if administrators do not re-authenticate the application before the deadline.