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.
Why This Matters for Security Teams
When an identity provider API exposes client secrets, the problem is not just exposure of a single value. It turns an administrative surface into a bulk credential source, which can be used to mint tokens, impersonate services, and pivot into downstream systems that trust the same tenant. That is why NHIs are treated as a security class rather than as simple configuration data in the OWASP Non-Human Identity Top 10.
The operational risk is amplified by secrecy sprawl and weak lifecycle control. NHIMG research on Guide to the Secret Sprawl Challenge shows that secret exposure often persists across tickets, code, and collaboration tools long after teams believe a secret is “private.” In practice, many security teams encounter this only after token abuse or tenant-wide impersonation has already started, rather than through intentional review.
How It Works in Practice
An identity provider API should never expose client secrets to broad read access. A secret is a credential, not metadata, and once it is retrievable at scale the API becomes a harvesting path. Attackers with valid platform access can enumerate applications, copy secrets, and exchange them for access tokens. Those tokens may then authenticate to APIs, message queues, CI/CD systems, or internal services that were never meant to be directly reachable from the original endpoint.
Security teams should treat this as both a design flaw and a governance failure. The correct pattern is to keep secrets out of read APIs entirely, use administrative workflows for creation and rotation, and rely on short-lived credentials wherever possible. The OWASP Non-Human Identity Top 10 aligns with this view: secrets should be tightly scoped, rotated, and protected from casual disclosure, especially where one secret unlocks many workloads.
- Return identifiers, status, and expiry metadata, but never the live secret itself.
- Store client secrets in a dedicated secrets system, not in the identity provider’s general-purpose read path.
- Rotate or revoke secrets immediately if an API design flaw makes exposure possible.
- Prefer workload identity and ephemeral tokens for service-to-service authentication.
NHIMG’s 52 NHI Breaches Analysis and the 2025 State of NHIs and Secrets in Cybersecurity both reflect the same operational pattern: exposed secrets tend to be reused, duplicated, and left active far beyond their intended scope. These controls tend to break down when secrets are embedded in automation and there is no reliable inventory of every consuming service.
Common Variations and Edge Cases
Tighter secret protection often increases operational overhead, requiring organisations to balance fast service onboarding against stronger credential control. Current guidance suggests that teams should distinguish between public configuration, sensitive metadata, and secrets, because mixing the three is where exposure begins.
There is no universal standard for whether an identity provider may expose a masked secret reference, a last-rotated timestamp, or a one-time reveal flow. The safer pattern is to limit any reveal to a controlled creation or rotation event, with strong audit logging and explicit approval. For mature environments, that posture fits the intent of the OWASP Non-Human Identity Top 10 while remaining compatible with the operational realities documented in The 2024 State of Secrets Management Survey.
Edge cases appear in multi-tenant admin portals, migration tooling, and support consoles where operators expect to “see everything.” Those workflows need compensating controls such as just-in-time access, break-glass approvals, and secret redaction by default. The biggest exception is incident response tooling, where a short-lived reveal may be justified, but only if the secret is immediately rotated afterward and downstream trust is fully revalidated.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Exposing client secrets is direct NHI credential exposure risk. |
| NIST CSF 2.0 | PR.AC-1 | Client secret exposure is an authentication and access control failure. |
| NIST AI RMF | This is about governing sensitive automated access and misuse risk. |
Document who can retrieve secrets, monitor abuse, and require accountable controls for every secret workflow.
