OAuth2 and OpenID Connect are standard protocols used to authenticate clients and authorise access to services. In an agentic context, they let an AI agent obtain tokens, present identity, and be evaluated by existing access-control systems without custom authentication flows. They provide a familiar foundation for machine identity integration.
Expanded Definition
OAuth2 and openid connect are closely related standards, but they solve different problems. OAuth2 is the delegation layer for access to APIs and services, while OpenID Connect adds an identity layer so a relying party can verify who the subject is. In practice, many platforms combine them, which is why the terms are often used together in modern identity discussions.
For NHI and agentic systems, this matters because a software agent may need both an access token and a verifiable identity assertion before downstream systems will trust it. That lets organisations reuse existing access-control and audit logic instead of inventing custom authentication for every tool or workflow. The boundary is important: OAuth2 does not by itself prove identity, and OpenID Connect does not replace authorisation decisions. In industry usage, definitions vary across vendors, especially around how much identity assurance is actually implied by an OIDC login flow.
OpenID Foundation documents the protocol relationship clearly in its OpenID Connect Core materials, which is the most direct source for understanding where authentication ends and delegation begins.
Examples and Use Cases
- An AI coding assistant uses OAuth2 to request scoped access to a source-code repository, then presents OIDC-based identity to satisfy the platform's session policy.
- A service integration exchanges an authorisation code for a token so it can read calendars or tickets without storing a human user's password.
- A workload or bot uses OIDC federation to obtain short-lived cloud credentials, reducing the need for long-lived shared secrets.
- A third-party SaaS app requests consented access to mailbox data, and the organisation must decide whether the scopes match the intended business use.
- An agentic workflow chains multiple tools, but the tradeoff is that each hop must preserve token scope, audience, and session context or trust can be overstated.
In this pattern, the protocol is often the difference between a controlled delegated access model and an ad hoc secret-sharing model. That distinction is why OAuth2 and OIDC are often the first standards practitioners reuse when they want machine access to fit existing identity governance.
Security Implications
Misunderstanding the protocol boundary can create real exposure. If OAuth scopes are too broad, an app or agent can access more data than the task requires. If OIDC claims are treated as stronger identity proof than they really are, downstream systems may over-trust a token that only proves a login event, not device posture, business legitimacy, or safe intent.
The most common failure modes are excessive consent, weak audience restriction, long-lived refresh tokens, and poor visibility into third-party applications. NHIMG research found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes token sprawl and delegated access hard to govern at scale. Once a token or federated credential is stolen, the attacker often inherits the application's existing trust path instead of needing to bypass MFA again.
Astrix Security & CSA reports that lack of credential rotation is the top cause of NHI-related attacks for 45% of organisations, which reinforces how quickly delegated access becomes a durable foothold when lifecycle controls are weak.
Domain and Governance Relevance
In NHI governance, OAuth2 and OpenID Connect are not just login plumbing. They are the policy interface through which agents, workloads, and SaaS integrations obtain trust, scope, and accountability. That means ownership of the app registration, consent model, token lifetime, and revocation path becomes a governance question, not just an engineering detail.
For non-human identities, the practical issue is whether an automated actor can be issued access in a way that is traceable, limited, and removable. When these standards are used well, they support least privilege, short-lived access, and auditability. When they are used loosely, they make it easy to accumulate shadow integrations that are technically valid long after the original business need has changed.
NHIMG treats this as a central machine-identity control surface because it determines whether agents can participate in existing IAM systems without creating separate, ungoverned authentication paths.
Risk and Threat Considerations
OAuth2 and OpenID Connect are attractive attack surfaces because they concentrate delegated trust in bearer tokens, app consents, and federated sessions. The material risk is not the protocol itself, but the way compromised tokens, overbroad scopes, or weak third-party app governance can turn a single approval into persistent access.
Failure mechanism: Attackers typically target consent abuse, token theft, misconfigured redirect flows, or over-privileged app registrations. Because bearer tokens are reusable until expiry or revocation, a stolen token can bypass interactive authentication and inherit the same access the legitimate app already had.
Impact: The result can be mailbox access, data exfiltration, lateral movement through trusted SaaS integrations, or long-lived access that survives password resets. In machine-identity environments, the blast radius can extend across many systems if the same app registration or federation trust is reused broadly.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secrets and Credential Management | OAuth/OIDC depend on tokens and federated credentials that must be protected and rotated. |
| NHI-03 — Access Governance and Least Privilege | Scopes, consent, and app registrations define machine access boundaries. | |
| NHI-01 — Inventory and Ownership | OAuth apps and OIDC trust relationships require accountable ownership and visibility. | |
| Recommendation — Protect and rotate delegated tokens and credentials to limit reusable access. Restrict OAuth scopes and app grants to the minimum access required. Assign owners to every OAuth app and federated trust before it goes live. | ||
| CIS Controls v8 | 6 — Access Control Management | OAuth and OIDC implement access control decisions for users, apps, and agents. |
| Recommendation — Review and revoke delegated access paths when business need or risk changes. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The standards support authentication and access enforcement across systems. |
| Recommendation — Enforce authentication and access rules consistently for federated and delegated identities. | ||
Practitioner Guidance
Why practitioners should care: Treat OAuth2 and OpenID Connect as governed trust infrastructure, not as a convenience layer. The key decision is whether each agent, app, or integration has a clearly owned registration, tightly scoped permissions, and a revocation path that actually works when the business need ends.
What to watch for: Unreviewed third-party consent, refresh tokens that outlive their purpose, and OIDC logins being mistaken for strong identity assurance are the common warning signs. Those patterns usually indicate that delegated access has outgrown the control model that originally approved it.
Practitioner takeaway: If a non-human actor can use these standards, it should be managed with the same discipline as any other privileged integration: named owner, bounded scope, and continuous review.
Related resources from NHI Mgmt Group
- How should security teams decide whether OAuth2 or OpenID Connect is actually needed for a new system?
- What do teams get wrong about session management when they build on OAuth2 and OpenID Connect?
- What is OpenID Connect (OIDC) and how does it extend OAuth 2.0 for NHIs?
- Why does JWE matter in OAuth and OpenID Connect flows?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
