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.
At a glance
What this is: Clutch Security’s analysis shows that a OneLogin API vulnerability exposed OIDC client secrets from a tenant application listing endpoint, turning ordinary API access into broad credential exposure.
Why it matters: IAM teams need to treat shared IdP API access as a high-risk trust boundary because one mis-scoped integration can expose secrets across many connected applications.
By the numbers:
- OneLogin serves over 5,500 enterprise customers globally.
Context
A client secret exposure in an identity provider is not just an API issue, because the secret often becomes the credential that lets one application impersonate another. In this case, the exposed values sat inside OneLogin’s OIDC application listing flow, which means the trust boundary was the tenant-wide application inventory itself.
For IAM and NHI programmes, the important issue is not whether the API was reachable, but whether shared API credentials were granted access broad enough to expose every connected integration. When vendor access, tenant-level application inventory, and OIDC client secrets converge, a single credential boundary can become a supply chain amplifier.
Key questions
Q: What breaks when an identity provider API exposes client secrets?
A: A read-only endpoint becomes a credential harvesting path. Attackers with valid API access can collect client secrets in bulk, impersonate applications, and use the resulting tokens to reach connected services. The failure is not limited to one app because OIDC secrets often authenticate many downstream systems that rely on the same tenant.
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. If a third party can query a tenant-wide application inventory, one compromised or misused API key can expose secrets for many connected services. The result is a trust-radius problem, where one relationship can affect multiple downstream identity and access pathways.
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. Rotate the affected client secrets, verify which services trust those applications, and inspect authentication logs for unusual token requests or new application impersonation. The goal is to reduce the blast radius before compromised secrets are reused elsewhere.
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.
Technical breakdown
Why a tenant application listing endpoint should never return client secrets
An application listing endpoint is supposed to return inventory data such as names, identifiers, and configuration metadata. Client secrets are authenticators, not inventory fields, so returning them in plaintext breaks the separation between discovery and credential custody. In OIDC, a client secret lets an application authenticate to the identity provider during the token exchange. Once that secret is exposed, an attacker can impersonate the application and obtain tokens without attacking the application itself. The failure here is architectural: the API response mixed low-sensitivity metadata with high-sensitivity authentication material.
Practical implication: review identity-provider APIs for any response fields that blur metadata and secret custody.
How broad API credentials turn OneLogin-style exposure into supply chain risk
The article describes a model where shared API keys often have broad endpoint access, including inventory endpoints for all applications in a tenant. That means a third party with legitimate API access may be able to enumerate far more secrets than its business function requires. This is a classic trust-radius problem: the credential is not only proof of who called the API, but a pass to everything the role can reach. When the exposed secret belongs to an OIDC application used for downstream SaaS, cloud, or internal systems, the blast radius extends beyond the identity platform itself.
Practical implication: scope third-party API access to the smallest possible endpoint set and treat inventory APIs as high-risk surfaces.
Why exposed OIDC client secrets create impersonation opportunities
OIDC client secrets are used in OAuth client credentials and related flows to prove application identity. If an attacker can retrieve those secrets, they can request tokens as the application and reach services that trust the application’s identity. That shifts the problem from secret leakage to identity impersonation. In practical terms, any connected service that accepts the application as a trusted caller becomes part of the attack surface. This is why secret exposure in identity infrastructure is so dangerous: the secret is not the prize, it is the mechanism for downstream access.
Practical implication: classify OIDC client secrets as reusable identity credentials and rotate them whenever exposure is suspected.
Threat narrative
Attacker objective: The attacker aims to impersonate OIDC applications and reach connected enterprise services through stolen client secrets.
- Entry occurs through valid OneLogin API credentials used to request a bearer token and access the application listing endpoint.
- Credential access follows when the endpoint returns plaintext OIDC client secrets alongside standard application metadata.
- Escalation happens when those secrets are used to impersonate applications and obtain access tokens for connected services.
- Impact is tenant-wide authentication exposure across the downstream systems that trusted the compromised OIDC applications.
Breaches seen in the wild
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
- SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Shared API credentials create trust-radius debt. The article shows that organisations often give vendors broad API access for convenience, then inherit the consequences when a vulnerable endpoint exposes more than intended. That is a governance problem because the credential carries wider authority than the business purpose that justified it. The implication is that third-party access reviews must account for endpoint-level exposure, not only role names or integration purpose.
Client secret custody and application inventory must be separated at the API layer. Once inventory endpoints can reveal authenticators, the design itself has failed to preserve least privilege. This is especially damaging for OIDC because the exposed secret can be used to impersonate the application rather than merely inspect it. Practitioners should regard this as a failure mode in identity architecture, not a one-off coding mistake.
Tenant-wide authentication visibility is the right control lens for this class of exposure. One secret leak in a central identity platform can affect many applications, many vendors, and many downstream teams at once. That makes blast-radius analysis more important than single-application hardening. NHI and IAM programmes should therefore align on a shared view of where application credentials live, who can query them, and how quickly they can be revoked when exposure is suspected.
Application client secret exposure is the kind of issue that proves identity infrastructure is a critical control plane. The practical lesson is that identity teams cannot treat API design, vendor integrations, and secret lifecycle as separate problems. In a connected enterprise, the control plane itself becomes the target surface, so governance must span access scope, secret custody, and downstream trust relationships.
From our research library:
- 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.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Supply chain risk now includes identity-provider response design. When a management API returns secrets, the weak point is not only access control, but how the control plane packages data for callers. That means IAM teams should review application inventory APIs with the same scrutiny they apply to authentication flows and secret stores.
Identity blast radius is the more useful planning term than simple exposure count. One tenant-level leak can affect many applications, many vendors, and many downstream trust relationships at once, so the security question becomes how far one compromised credential can travel. In practice, that changes remediation from single-object patching to tenant-wide secret lifecycle review.
For practitioners
- 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.
- Review third-party API trust boundaries Reassess every vendor and contractor that holds IdP API credentials, including what those credentials can see, export, or impersonate inside the tenant.
- Monitor for application impersonation patterns Look for unexpected token requests, unfamiliar client authentication flows, and downstream logins that occur after secret rotation or disclosure events.
Key takeaways
- A tenant-level API that exposes client secrets turns ordinary identity management into a credential distribution problem.
- The article’s scale estimates show that one affected tenant can map to thousands of applications and many enterprise customers.
- The right control response is to separate inventory access from secret custody and rotate any potentially exposed client secrets.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on OIDC client secrets being exposed through an API response. |
| NHI-03 — Vulnerable Third-Party NHI | Shared vendor API credentials broaden the blast radius when a third party can reach tenant-wide secrets. | |
| NHI-05 — Overprivileged NHI | The vulnerable access model allowed broad retrieval of secrets beyond the caller's business need. | |
| Recommendation — Audit identity APIs for secret leakage and ensure authenticators never appear in inventory responses. Limit third-party API access to the minimum endpoints needed and review vendor-held credentials regularly. Reduce NHI privilege so management APIs cannot expose more applications than an integration requires. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack path moves from secret access to downstream impersonation and broader movement. |
| Recommendation — Map secret exposure paths to credential access and lateral movement so detections cover downstream misuse. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue stems from overly broad access permissions on an identity platform API. |
| Recommendation — Apply least-privilege entitlement reviews to identity-provider API access and remove unnecessary broad scopes. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The incident is fundamentally about cloud identity management and tenant-level access control. |
| Recommendation — Review cloud identity APIs under the IAM domain and separate metadata access from secret handling. | ||
Key terms
- OIDC Client Secret: A client secret is the shared credential an application uses to prove itself to an identity provider during OpenID Connect flows. In practice, it functions like an application password, so exposure can let an attacker impersonate the application and obtain tokens for connected services.
- Tenant-wide Application Inventory: A tenant-wide application inventory is the full set of applications configured in a single identity provider tenant. When that inventory is exposed through an API, the risk is not only discovery of apps, but disclosure of the secrets that let those apps authenticate.
- Trust Radius: Trust radius is the amount of damage a credential or integration can create if it is abused. In identity security, the term is useful because a single API key or secret can reach far beyond the narrow business task that justified its issuance.
- Key Custody: Key custody is the ownership and control of cryptographic keys across their lifecycle, including storage, rotation, emergency use, and retirement. Poor custody turns encryption into a weak barrier because any identity with key access can recover data that should have remained protected.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org