SSO-OIDC Authentication Issue

What to do

• Check whether you use JumpCloud SSO OIDC - US Region in us. Check your stack

  Paste a package.json, lockfile, Terraform or a list of domains at down.guide/stack to see every provider you depend on.

• Confirm your retries, queues and scheduled jobs caught up after the 1h 19m it lasted.

  Anything that failed between 2025-11-06 12:28 UTC and 2025-11-06 13:47 UTC may need a replay.

• Subscribe to JumpCloud's feed to hear about the next one first. RSS feed

  https://down.guide/feed?provider=jumpcloud works in Slack (/feed subscribe), Discord feed bots and any RSS reader.

Updates from JumpCloud 5

1. investigatingNov 6, 2025, 12:28 PM UTC

   We are currently investigating an issue with the authentication on SSO OIDC applications. We have already identified the cause and will provide an update within one hour.

   provider

2. identifiedNov 6, 2025, 12:33 PM UTC

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

   provider

3. monitoringNov 6, 2025, 1:10 PM UTC

   A fix has been implemented and we are monitoring the results.

   provider

4. resolvedNov 6, 2025, 1:47 PM UTC

   This incident has been resolved.

   provider

5. postmortemNov 13, 2025, 11:33 PM UTC

    ‌ **Date**: Nov 13, 2025 **Date of Incident:** Nov 6, 2025 **Description**: RCA for SSO/OIDC Service Degradation ‌ **Summary:** On November 6, 2025, starting at approximately 12:00 UTC, customers experienced failures to launch any application relying on JumpCloud's OIDC-based Single Sign-On \(SSO\), lasting for roughly one hour. ‌ **Root Cause:** The outage was caused by a combination of two errors during a scheduled compliance procedure: 1. Faulty Password Generation: Our automated system for rotating database passwords created a new credential that contained unsafe special characters. 2. Missing Special Character Logic: The entrypoint script for our core SSO service was missing logic to handle these special characters before using the password to construct a database connection string. When the SSO service attempted to restart and use the newly rotated password, the presence of the unsafe characters caused the connection string to be misinterpreted as invalid, leading to a parsing failure and service degradation. This issue stemmed from a latent configuration bug that was masked by prior rotation processes. Previously, database passwords were rotated manually using an older system \(`random_password` IAC resource\) which was explicitly configured to only generate alphanumeric characters. These characters are inherently safe in a URL context, so the underlying bug in the SSO service's connection logic was never exposed.  When the credential management was successfully migrated to the new, more robust rotation process, the new function began generating highly complex passwords, including special characters, for the first time. This immediately triggered the latent parsing flaw in the SSO service’s entrypoint script. ‌ **Corrective Actions / Risk Mitigation:** 1. Hardening code logic - All services that construct database connection strings will be audited and updated to explicitly encode the password component eliminating character misinterpretation. 2. Enhanced rotation alerting -  New monitoring and alerting dashboards are in place to track the health and success schedule of all automated credential rotation jobs, providing an immediate alert if a rotation creates an invalid credential. 3. Update password generation logic - The automated credential rotation function has been updated to explicitly generate passwords that are safe, avoiding complex, reserved characters.

   provider

Corrections

None so far.

Something wrong on this page? Report an error or send us a note. Every fix is listed here.