SSO login failures for the published Harness Okta application

Update timeline

1. investigating Sep 29, 2026, 08:31 PM UTC

   We are currently investigating this issue.

2. identified Sep 29, 2026, 08:31 PM UTC

   The issue has been identified and a fix is being implemented.

3. identified Sep 29, 2026, 08:50 PM UTC

   We identified an issue affecting only the published Harness Okta application. After a recent update to that application, SSO login attempts returned an HTTP 400 error when the configured SSO URL was missing from Additional ACS URLs. Customers using that published application can immediately mitigate the issue by adding their Harness SSO URL to Additional ACS URLs in Okta. We are working on a permanent resolution.

4. identified Sep 29, 2026, 08:57 PM UTC

   We identified an issue that applies only to SP-initiated login through the published Harness Okta application. After a recent update to that application, those login attempts returned an HTTP 400 error when the configured SSO URL was missing from Additional ACS URLs. General SAML 2.0 configurations in Okta are not affected. Immediate Solutions: Use IDP-initiated login. Start the login from the Harness application tile in Okta. Or Add your Harness SSO URL to Additional ACS URLs in the published Harness Okta application.

5. resolved Oct 02, 2026, 12:33 AM UTC

   This incident has been resolved.

6. postmortem Oct 07, 2026, 06:30 PM UTC

   # 1. Summary Starting September 29, 2026, customers who sign in to Harness through the published Harness application in the Okta Integration Network \(OIN\) were unable to complete SP-initiated SSO login. Affected users received an HTTP 400 error from Okta instead of being signed in. The issue was introduced by a change in how Okta validated the requested reply \(ACS\) URL for existing installations of the published Harness application. Workarounds were published within an hour of the first report, and every affected customer was unblocked. # 2. Impact ‌ * Impact was limited to customers using the published Harness application from the Okta Integration Network for SP-initiated login \(starting sign-in from Harness\). Those attempts returned an HTTP 400 error from Okta. * IdP-initiated login, started from the Harness tile in Okta, continued to work throughout. * Customers using their own generic SAML 2.0 application configuration in Okta were not affected. * No customer data was lost or exposed. # 3. Root Cause On September 29, 2026, an updated version of the Harness application was published to the Okta Integration Network. The update added support for registering multiple reply \(ACS\) URLs, so that customers running Harness across several regions or environments could configure more than one callback URL. Harness includes an AssertionConsumerServiceURL value in the SAML authentication request it sends to Okta. Before this update, Okta did not validate that value for application instances that had no additional ACS URLs configured, and simply returned the SAML assertion to the application's default ACS URL. After the update, this validation became active on all existing instances of the application, including those where the customer had never configured an additional ACS URL. Because the requested value was not present in the instance's registered list, Okta rejected the authentication request with an HTTP 400 error. The updated application went through Okta's standard OIN publishing review, which includes backward compatibility verification against existing installations of a published integration. This change in validation behavior for instances with no additional ACS URLs configured was not surfaced during that review, so it reached customers at release. # 4. Remediation **Immediate Response** Two workarounds were published on the status page: sign in from the Harness tile in Okta \(IdP-initiated login\), which was unaffected; or register the application's Okta SSO URL in the Additional ACS URLs field of the Harness Okta application. Support engaged each affected customer directly and validated sign-in with them. ‌ **Resolution** Rolling the application back to the previous version was deliberately avoided, as that would only defer the same disruption to the next release. Every affected customer was instead unblocked through the ACS URL registration, and we are working with Okta to make the ACS URL validation conditional again, so that instances with no additional ACS URLs configured behave exactly as they did before and no customer action is required. # 5. Action Items To prevent such issues from happening again, we are working on | **Action Item** | | --- | | Working with Okta to restore conditional ACS URL validation, so instances with no additional ACS URLs configured behave exactly as before and no customer action is required. | | Publish a dedicated configuration guide for the Harness OIN application in Harness documentation, including reply \(ACS\) URL requirements. | | Add an independent pre-release verification step against existing customer configurations for any future update to the published Okta application, alongside Okta's own review. | | Migrate user authentication to Harness ID, which removes the dependency on this validation behavior entirely. |