What do security teams get wrong about using OAuth and OpenID Connect in IAM programmes?

Why This Matters for Security Teams

OAuth and openid connect are often introduced as clean answers to modern access problems, but security teams get into trouble when they assume protocol adoption equals control. OAuth governs delegated authorisation, not blanket trust, while OpenID Connect adds authentication claims that still need policy, lifecycle, and logging discipline. The gap shows up fast in third-party app sprawl, token abuse, and weak consent governance, especially in environments that already struggle with non-human access. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls remains relevant here because protocol choice does not remove the need for access review, monitoring, and revocation.

The operational risk is not theoretical. NHIMG research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, and that lack of visibility turns a convenience protocol into a persistent access channel. Breaches such as the Salesloft OAuth token breach and the Klue OAuth Supply Chain Breach show how quickly delegated access can outlive the original security assumptions. In practice, many security teams discover the weakness only after a connected app has already been granted broad, durable access.

How It Works in Practice

The main mistake is treating OAuth scopes, consent screens, and OIDC login events as if they were complete access governance. They are not. OAuth answers the question of what a client application may do on behalf of a resource owner, while OpenID Connect answers who the authenticated subject is and how that identity was asserted. Security teams still need to decide whether the requested action is appropriate, whether the token should be short lived, and whether the application is allowed to retain access after the original business need ends.

In mature programmes, the control model usually includes:

• tight scope design so tokens carry only the minimum delegated rights
• short token lifetimes and refresh token restrictions to reduce replay value
• admin consent governance for high-risk or multi-tenant apps
• continuous review of connected apps, grants, and inactive tokens
• centralised logging that links token issuance, consent, and downstream API use

This is where policy and identity separate. OIDC claims can support session decisions, but they do not replace contextual authorisation or privileged access management. For example, a signed-in user or workload may be authenticated correctly and still be far too powerful once the token is minted. That is why teams pair protocol controls with access standards such as OpenID Connect Core 1.0 and stronger operational guidance from RFC 6749, then enforce lifecycle actions on tokens and app registrations.

For non-human identities, the problem becomes sharper because OAuth is often used as a transport for long-lived trust, not a temporary delegation mechanism. NHIMG’s reporting on the State of Non-Human Identity Security highlights how visibility gaps and over-privileged accounts remain common, and incidents like the OneLogin API Key Vulnerability underscore the danger of treating secrets and federated tokens as interchangeable. These controls tend to break down in SaaS-heavy environments with weak app inventories and no reliable owner for each grant.

Common Variations and Edge Cases

Tighter OAuth governance often increases administrative overhead, so organisations need to balance user experience against the risk of silent privilege accumulation. That tradeoff becomes especially visible in multi-tenant SaaS, partner integrations, and machine-to-machine flows where business owners want low-friction onboarding but security teams need explicit approval paths.

There is no universal standard for every edge case, but current guidance suggests treating the following differently:

• Public client apps should not be managed like confidential server-side integrations.
• OIDC login for workforce SSO should not be assumed to authorise downstream API access.
• Service accounts using OAuth should be reviewed like other non-human identities, not exempted because they are “just integrations”.
• Consent should be revocable, auditable, and periodically revalidated, especially for third-party apps.

Security teams also need to watch for consent phishing, shadow IT app registrations, and over-broad tenant-wide permissions. NHIMG’s analysis of OAuth-related incidents, including the Microsoft OAuth Breach, shows that the real weakness is rarely the protocol itself. It is the organisational habit of treating issued tokens as if they remain safe and justified forever.

Related resources from NHI Mgmt Group

• What do security teams get wrong about using native cloud IAM tools at scale?
• What do security teams get wrong about using APIs to manage user roles and application licences?
• What do security teams get wrong about using awards as a measure of product quality?
• What do security teams get wrong about professional-services-heavy IAM programmes?