Topic starter
07/06/2026 9:20 pm
TL;DR: A critical OneLogin API flaw exposed OIDC application client secrets to any actor with valid API credentials, affecting an estimated 110,000 to 275,000 applications across more than 5,500 enterprise customers, according to Clutch Security.
Editorial analysis by NHI Mgmt Group, based on content published by Clutch Security: “OneLogin, Many Secrets: Clutch Uncovers Critical API Vulnerability Exposing Client Credentials”.
By the numbers:
- OneLogin serves over 5,500 enterprise customers globally.
Key questions
Q: What breaks when an identity provider API exposes client secrets?
A: A read-only endpoint becomes a credential harvesting path.
Q: Why do shared IdP API credentials create supply chain risk?
A: Because the credential usually carries broader reach than the vendor’s narrow job function.
Q: How should IAM teams respond when OIDC client secrets may have been exposed?
A: Treat the exposure as reusable credential compromise, not as a routine configuration issue.
Practitioner guidance
- Audit identity-provider API scopes Map every integration that can query tenant-level application inventory and remove any broad access that is not required for a specific business function.
- Rotate exposed OIDC client secrets Regenerate client secrets for every application that could have been returned by the vulnerable listing endpoint, then confirm downstream services have reauthenticated cleanly.
- Separate inventory access from secret custody Ensure management APIs can enumerate applications without returning authenticators, and verify that secrets are stored and delivered through a distinct control path.
Bottom line: A tenant-level API that exposes client secrets turns ordinary identity management into a credential distribution problem.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
08/06/2026 9:13 am
Identity-provider API exposure is a supply chain problem, not a narrow application flaw. When a tenant-level API returns client secrets, the issue is no longer limited to one integration or one vendor relationship. The breach path turns identity inventory into credential inventory, which means the downstream blast radius belongs to every connected service that trusts those secrets. Practitioners should treat identity-provider APIs as part of the authentication perimeter, not as ordinary management interfaces.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
A question worth separating out:
Q: What is the difference between application metadata and client secrets in IAM?
A: Application metadata describes the object, while a client secret proves the object’s identity during authentication. Metadata can usually be disclosed for administration and discovery, but client secrets must remain confidential because they are credentials. Mixing the two in a single API response creates an avoidable control failure that exposes identity trust to abuse.
👉 Read our full editorial: OneLogin API secrets exposure shows the supply chain blast radius