OAuth login risk is still widening enterprise attack surface

At a glance

What this is: This article explains how social logins and OAuth permissions expand unmanaged SaaS access, with 1Password arguing that visibility and permissions monitoring are the real control gaps.

Why it matters: It matters because IAM teams have to govern access that sits outside traditional SSO, spanning human identities, SaaS apps, and non-human permissions that can expose sensitive data.

By the numbers:

• 27% of employees have used the same passwords for both their work and personal accounts.

👉 Read 1Password's analysis of OAuth login risk and SaaS access visibility

Context

Social login changes the identity boundary because authentication and authorization are split across providers and apps. OIDC verifies who the user is, while OAuth grants the app permission to access data or take actions on the user’s behalf. For IAM teams, that creates a control plane outside the main SSO flow, where visibility into scope, app usage, and third-party access can be uneven.

The practical issue is not that OAuth is inherently unsafe. The issue is that broad scopes, unmanaged app approvals, and user workarounds can create access paths that security teams do not continuously review. That is where SaaS governance, permission visibility, and lifecycle controls have to extend beyond the corporate identity boundary.

Key questions

Q: How should security teams govern OAuth access in SaaS environments?

A: Security teams should treat OAuth access as governed permission, not a one-time login event. That means inventorying connected apps, reviewing scopes, assigning ownership, and revoking grants that no longer match business need. The strongest programme connects SaaS discovery to lifecycle governance so app access is reviewed when roles change or users leave.

Q: Why do social logins create security risk for IAM programmes?

A: Social logins create risk because authentication happens in one place while authorization can extend into many external apps. Users may approve broad scopes without understanding them, and those grants can persist outside normal SSO oversight. IAM programmes lose visibility when access is distributed across third-party SaaS and not continuously reviewed.

Q: What breaks when OAuth permissions are only reviewed manually?

A: Manual review breaks at scale because access changes faster than periodic audits. Teams miss newly approved apps, users can re-grant access later, and high-risk scopes stay hidden until an incident or compliance check. The result is a governance cycle that is always behind the actual permission state.

Q: Should organisations block all social logins to reduce risk?

A: Blocking everything usually creates workarounds and does not solve the underlying governance problem. A better approach is to allow approved social logins, restrict dangerous scopes, and continuously monitor connected apps. That preserves usability while keeping delegated access visible enough to manage.

Technical breakdown

OIDC versus OAuth 2.0 in social login

OpenID Connect is the authentication layer. It confirms that a user is who they claim to be by delegating login to an identity provider. OAuth 2.0 is the authorization layer. It grants the application permission to access resources, often through scopes such as read mail, manage files, or modify settings. In practice, many teams treat the two as one feature, but the security consequences differ. A social login can be legitimate while the OAuth grant is excessive. That distinction matters because the app may be trusted to authenticate a user yet still be over-authorized once consent is granted.

Practical implication: Separate identity verification review from OAuth scope review so you do not confuse successful sign-in with safe authorization.

OAuth scopes and third-party SaaS exposure

OAuth scopes define what an app can do after consent is granted. The risk grows when users approve access without understanding the permission set, especially in third-party SaaS apps that sit outside central IAM controls. Because permissions can persist after initial approval, a single grant can become durable access to email, documents, calendars, or admin functions. This is why shadow SaaS and unmanaged integrations matter. The exposure is not just the number of apps, but the authority each app inherits once connected to a user account or tenant.

Practical implication: Review high-risk scopes first, then remove any app permissions that do not match a clear business owner and documented use case.

Why manual OAuth review fails at scale

Manual review can identify risky apps, but it does not scale well across thousands of SaaS connections. Teams have to inspect each app, evaluate permissions, determine ownership, and revoke access where needed. That creates delay, human error, and re-grant risk, because users can approve the same app again later. The technical problem is that OAuth consent is event-driven while governance is periodic. When access changes faster than review cycles, security teams lose a reliable picture of who can reach what, and for how long.

Practical implication: Automate discovery and permission monitoring so OAuth review happens continuously rather than only during audit cycles.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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

NHI Mgmt Group analysis

OAuth consent has become a shadow access channel, not just a convenience feature. The article shows how user-approved app access can bypass the visibility and review habits that IAM teams rely on in SSO-centric environments. That matters because the effective control boundary shifts from the corporate directory to every third-party app that can inherit permissions. Practitioners should treat consented access as part of the identity estate, not a peripheral app setting.

Persistent OAuth scope is a governance problem, not an authentication problem. The user may authenticate correctly and still hand an application broad, long-lived authorization. That means the real control question is whether app permissions are bounded, owned, and revisited after approval. IAM and SaaS management teams should evaluate whether their programme measures access grants with the same seriousness as password or session controls.

Shadow SaaS is where access reviews lose fidelity. When applications appear outside the sanctioned stack, recertification and offboarding processes miss the permissions that matter most. This article reinforces that access governance must extend to SaaS discovery, consented app inventory, and permission revocation workflows. Practitioners should assume that the riskiest access is often the access nobody has catalogued.

Identity governance is moving from account-centric to permission-centric control. The useful unit of review is no longer just the user or the app, but the combination of user, app, scope, and data domain. That is the model that can cover human identities, SaaS access, and non-human permissions in one governance view. Teams that keep reviewing identities without reviewing grants will continue to miss the actual blast radius.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• For a broader control lens, review Top 10 NHI Issues alongside OAuth governance so app grants and NHI controls are assessed together.

What this signals

Consent visibility is becoming a governance baseline. When users can grant apps access outside the primary identity stack, security teams need continuous discovery rather than periodic review. The control question is no longer whether the login succeeded, but whether the resulting grant is visible, owned, and revocable across the full SaaS estate.

Identity programmes will increasingly measure permissions rather than just accounts. The useful governance unit is the grant, because that is what determines access to data and actions. Teams that only track users and applications will keep missing the authority created at consent time.

With 1 in 4 organisations already investing in dedicated NHI security capabilities, according to The State of Non-Human Identity Security, the market is signalling that permissions, tokens, and delegated access are now mainstream identity concerns, not edge cases.

For practitioners

• Inventory all OAuth-connected applications Build a complete list of apps connected through social login or delegated consent, then assign a business owner to each one. Include read, write, admin, and offline-access permissions so review starts with the highest-risk grants.
• Prioritise scope-based access reviews Review granted OAuth scopes before you review generic app usage, because the scope determines what the app can actually do. Start with email, file, calendar, and directory permissions, then remove grants that exceed the documented use case.
• Automate discovery of shadow SaaS and AI tools Use continuous discovery to find unsanctioned apps that users connect through Google Workspace or similar identity providers. The goal is to identify re-grant risk early and prevent hidden access from surviving past the original approval.
• Tie OAuth revocation to lifecycle events Remove delegated access when a user changes role, leaves a team, or no longer needs the app. Treat revocation as part of joiner-mover-leaver governance, not as an isolated cleanup task.

Key takeaways

• OAuth access is a governance problem because delegated consent can outlive the sign-in event and widen access outside central SSO controls.
• The scale of the visibility gap is material, with 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps.
• IAM teams should shift from account-only review to scope-based discovery, ownership assignment, and lifecycle-linked revocation.

Key terms

• OpenID Connect: OpenID Connect is the authentication layer that lets an application rely on an external identity provider to confirm a user’s identity. It answers who the user is, but not what the application may do after login. In practice, it sits alongside OAuth and often shapes the sign-in experience that users trust without examining the resulting permissions.
• OAuth 2.0: OAuth 2.0 is an authorization framework that lets a user or identity provider grant an application permission to access resources on their behalf. The key security issue is scope, because the app may receive durable access to data or actions that are broader than the user intended. Governance therefore has to review grants, not just logins.
• Social Login: Social login is a sign-in pattern that uses an external identity provider such as Google to authenticate users into another application. It reduces password friction, but it also creates delegated access paths that can widen the attack surface if permissions, scopes, and connected apps are not continuously governed.
• Shadow SaaS: Shadow SaaS is the set of applications adopted or connected without full security visibility or formal approval. These apps can inherit identity permissions through social login or OAuth, which means the risk is not just unmanaged software but unmanaged access authority tied to that software.

Deepen your knowledge

OAuth governance and delegated access reviews are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is extending beyond SSO into SaaS consent and third-party app control, it is worth exploring.

This post draws on content published by 1Password: OAuth login risk and visibility in SaaS environments. Read the original.