OpenID Connect discovery is the metadata document that tells clients where to find identity endpoints such as jwks_uri. It removes hardcoded configuration from clients, but it also makes discovery integrity part of the trust chain, so teams should always fetch and validate it over HTTPS.
Expanded Definition
openid connect discovery is the machine-readable metadata that lets a client locate identity endpoints, issuer details, and signing keys without hardcoding them. In practice, it is a trust input, not just a convenience feature, because the client depends on the discovery document to know which issuer and NIST Cybersecurity Framework 2.0 style control assumptions apply to the authentication flow.
For NHI and agent-driven systems, discovery matters because workloads often authenticate automatically, at scale, and across multiple environments. That makes endpoint correctness and metadata integrity part of the security boundary. Definitions vary across vendors on how aggressively clients should pin issuers, cache metadata, or re-fetch configuration, but the core expectation is consistent: discovery should be retrieved over HTTPS, validated, and monitored for drift. The most common misapplication is treating discovery as a one-time bootstrap file, which occurs when teams trust cached metadata indefinitely after issuer or key rotation.
Examples and Use Cases
Implementing OpenID Connect discovery rigorously often introduces operational dependency on metadata freshness, requiring organisations to weigh authentication resilience against the risk of stale or poisoned configuration. That tradeoff is especially important for automated systems that cannot tolerate repeated manual reconfiguration.
- A service account in CI/CD uses discovery to find the issuer, token endpoint, and JWKS URI before exchanging a client credential for a token.
- An AI Agent authenticates to a tool API through an OpenID Connect provider, using discovery so the integration survives endpoint changes without code edits.
- A platform team centralises federation across cloud accounts, then uses discovery to keep the client aligned with the current signing keys and endpoint set.
- Security engineering uses discovery validation to detect when an identity provider metadata document changes unexpectedly during rotation or misconfiguration.
For NHI programs, these patterns should be paired with lifecycle discipline from the NHI Lifecycle Management Guide, because discovery only helps when the underlying issuer, client registration, and secret handling are governed end to end. The same control intent appears in vendor-neutral guidance such as NIST Cybersecurity Framework 2.0, which emphasises managed, observable security processes rather than static configuration.
Why It Matters in NHI Security
Discovery integrity becomes critical when workloads, agents, and service identities authenticate without human review. If a discovery document is replaced, redirected, or simply left stale after issuer changes, the result can be failed logins, token validation errors, or worse, silent trust in the wrong signing authority. This is why the issue sits close to broader NHI governance concerns highlighted in Top 10 NHI Issues and the Ultimate Guide to NHIs — Key Challenges and Risks.
NHIs outnumber human identities by 25x to 50x in modern enterprises, so a discovery flaw can affect far more automated actors than a single user login path. That scale means one weak federation assumption can cascade into broad token issuance, broken rotations, or misrouted authentication across applications, pipelines, and agents. Teams should treat discovery as part of the same trust chain as secrets, issuer validation, and key management, not as a benign configuration convenience.
Organisations typically encounter this issue only after a certificate change, issuer migration, or authentication outage, at which point OpenID Connect discovery becomes operationally unavoidable to address.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret and trust mismanagement around machine identity flows. |
| NIST CSF 2.0 | PR.AC-4 | Maps to managed access and identity validation for automated clients. |
| NIST Zero Trust (SP 800-207) | Discovery supports trusted authentication in zero trust architectures. |
Review discovery-linked federation settings and enforce least privilege for service and agent identities.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
