OneLogin API secrets exposure shows the supply chain blast radius

At a glance

What this is: A OneLogin API vulnerability exposed OIDC client secrets through an application listing endpoint, allowing credential holders to retrieve secrets across a tenant.

Why it matters: It matters because one exposed API credential can now cascade into broad application impersonation, which affects NHI, human SSO, and downstream service access governance alike.

By the numbers:

• OneLogin serves over 5,500 enterprise customers globally.
• The CVSS base score for CVE-2025-59363 was 7.7.

👉 Read Clutch Security's analysis of the OneLogin API client secret exposure

Context

OneLogin API secrets exposure is a governance failure, not just a coding flaw. When an identity provider returns client_secret values in an endpoint designed for application metadata, the trust boundary around OIDC integrations breaks and the blast radius extends well beyond a single tenant.

Enterprises often share identity provider API credentials with vendors, contractors, or internal teams to support integrations. That normal operating model becomes dangerous when the platform itself broadens what those credentials can reveal, because the same access path can be reused to impersonate applications, obtain tokens, and reach connected services.

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 API credentials increase the impact of OIDC secret exposure?

A: Shared credentials often carry broader endpoint access than the integration actually needs. If an identity provider leaks secrets through that access path, the same key can reveal many application credentials at once. That turns a routine vendor integration into a tenant-wide risk because the credential holder can see far more than intended.

Q: How do security teams know if identity provider API access is too broad?

A: Check whether a vendor key can enumerate applications, read sensitive application fields, or reach endpoints unrelated to its stated integration purpose. If the key can see tenant-wide objects, its scope is too broad for delegated use. The practical signal is any API credential that can expose assets beyond one narrowly defined workflow.

Q: Who is accountable when exposed client secrets are reused in downstream applications?

A: Accountability is shared across the identity platform owner, the integration owner, and the teams that accepted the secret as a trust anchor. The immediate duty is to rotate the secret, notify dependent application owners, and verify token issuance paths. Identity governance fails when nobody owns the full trust chain.

Technical breakdown

How the /api/2/apps endpoint leaked OIDC client secrets

The vulnerable endpoint was intended to enumerate tenant applications, but it returned plaintext client_secret values alongside normal metadata. In an OIDC setup, the client secret is the application credential used during OAuth flows to prove the application is authorised to the identity provider. If that value appears in an API response, any caller with valid API access can harvest credentials at scale without attacking each application individually. The issue is compounded when the API permission model is broad, because the exposure is not limited to a single integration.

Practical implication: review every identity provider API response that can surface application metadata and confirm secrets never appear in read paths.

Why shared API credentials magnify identity provider risk

Shared API keys are often provisioned for convenience, not for narrow task boundaries. If a vendor or contractor receives a key with broad endpoint access, the key can become a tenant-wide discovery mechanism when the platform exposes more than intended. This is not just a secrets problem. It is a delegation problem, because the credential holder inherits visibility into assets that were never meant to be operationally linked. In OIDC-heavy environments, that means one integration credential can become the entry point for many downstream systems.

Practical implication: separate vendor-scoped access from tenant-wide identity administration and review every shared API key against actual endpoint necessity.

How exposed client secrets enable application impersonation and lateral movement

Once a client secret is disclosed, an attacker can authenticate as the application itself and complete OAuth client credentials or related flows to obtain tokens. Those tokens then open the door to connected services, which may include cloud platforms, databases, or business applications. The technical danger is not the secret alone, but the trust chain it unlocks. In identity terms, this is a classic credential-to-token-to-system escalation path, where one secret creates a reusable foothold across the integration stack.

Practical implication: rotate client secrets after any exposure event and map which downstream applications trust the affected OIDC integrations.

Threat narrative

Attacker objective: The attacker aims to turn one identity provider credential into broad impersonation capability across integrated enterprise applications.

1. Entry occurs when an attacker obtains valid OneLogin API credentials, often through shared vendor access or another credential compromise.
2. Credential access happens when the attacker calls the application listing endpoint and extracts plaintext OIDC client secrets from the API response.
3. Impact follows when the attacker uses the exposed client secrets to impersonate applications, obtain tokens, and reach connected services across the tenant.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

One API credential should never become a tenant-wide discovery tool. This incident shows that identity provider APIs must be governed as high-trust control planes, not ordinary application endpoints. When a read path exposes client secrets, the platform collapses the separation between metadata and credentials, and the result is a blast radius measured in downstream integrations, not just in the identity platform itself. Practitioners should treat API response hygiene as identity architecture, not implementation detail.

Shared vendor access is a delegation problem before it is a secrets problem. The breach path depended on valid API credentials that were likely issued for operational convenience and broader than necessary scope. That is the real governance gap: a shared credential becomes a hidden privilege layer when its effective reach is not bounded to a specific integration task. Organizations need to re-evaluate how much tenant visibility any third party truly requires.

Tenant-wide OIDC exposure is a supply chain multiplier, not a single-system failure. OIDC application secrets connect identity control to many other services, so one disclosure can echo across cloud, data, and business platforms. This is why identity provider security sits at the center of supply chain risk, especially where vendors and contractors receive API access. The practical conclusion is that downstream trust maps must be part of identity governance.

Client secret exposure window: a leaked application secret remains a latent impersonation credential until every dependent integration is reissued. That failure mode matters because the exposed secret is not just data, it is reusable authentication material that can survive beyond the discovery event. The implication is that incident review must track every application and service that trusted the secret, not only the platform that leaked it.

Broad API permissions and hidden credential disclosure are the control gap this breach exploited. The endpoint should have returned only application metadata, but the platform allowed a broad access credential to retrieve secrets it was never meant to see. That combination turns access review into a false comfort exercise, because the permission looked routine while the response behaved like privileged retrieval. Practitioners should challenge any IAM design where read access can silently reveal authentication material.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Another finding from our research shows that only 44% of developers are reported to follow security best practices for secrets management, which helps explain why leaked credentials persist after discovery.
• For a broader control view, read Guide to the Secret Sprawl Challenge for the operational patterns that turn one secret into many.

What this signals

Client secret exposure window: the operational problem is not only disclosure, but how long the credential remains valid across dependent services. In environments like this, the relevant programme question is whether your identity governance can identify every consumer of a secret before the exposure becomes an application impersonation event.

Identity teams should expect the control conversation to shift from endpoint hardening to trust-chain mapping. A tenant can have strong authentication and still fail if its API delegation model allows secrets to surface in places they were never meant to appear.

The most durable response is to treat identity provider APIs as part of the privileged attack surface and align their monitoring with broader controls in the OWASP Non-Human Identity Top 10 and Zero Trust guidance.

For practitioners

• Inventory every OneLogin API credential Identify which vendors, contractors, and internal teams hold identity provider API keys, then map each key to the exact endpoints it can reach. Remove credentials that are shared for convenience rather than required for a specific integration purpose.
• Rotate all OIDC client secrets tied to exposed tenants Regenerate client secrets for every OIDC application in the affected tenant and prioritise services that authenticate to cloud platforms, databases, or critical business applications. Validate that each dependent application is functioning with the new secret before closing the incident.
• Audit identity provider API responses for secret leakage Test listing, discovery, and management endpoints to confirm they return metadata only and never include client_secret values, tokens, or other credentials. Add this check to release validation for identity platform changes and regression testing.
• Map downstream trust chains from every OIDC integration Document which applications, services, and vendor workflows depend on each OIDC client secret so a future exposure can be contained quickly. This should include application impersonation paths, token scopes, and the service accounts or human users those tokens can reach.

Key takeaways

• This vulnerability showed that an identity provider API can become a tenant-wide secrets oracle when read access returns client_secret values.
• The scale matters because a single compromised API credential can expose hundreds or thousands of OIDC integrations across one tenant.
• The control that matters most is not only secret rotation, but strict API response hygiene and narrow delegated access scope.

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.
• Identity Provider API: An identity provider API is the administrative interface used to manage applications, credentials, policies, and tenant objects. It is a control plane, not a routine business API, which means any excessive response data or broad permission scope can create tenant-wide security exposure.
• Delegated Access Scope: Delegated access scope is the bounded set of actions and objects a third party is allowed to reach through an API key or token. When the scope is wider than the actual integration need, the credential becomes a reusable privilege layer that can expose unrelated assets.
• Application Impersonation: Application impersonation occurs when an attacker uses an application credential to act as that application in authentication flows. In identity systems, this is dangerous because the attacker inherits the trust relationships attached to the application, which can extend to cloud services, data stores, and internal tools.

Deepen your knowledge

OIDC client secret governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are managing shared identity provider access or preparing for secret exposure events, it is worth exploring.

This post draws on content published by Clutch Security: OneLogin, Many Secrets: Clutch Uncovers Critical API Vulnerability Exposing Client Credentials. Read the original.