TL;DR: Social logins and OAuth permissions make access easier, but they also expand unmanaged SaaS exposure when users reuse credentials or grant broad scopes, according to 1Password’s Annual Report and analysis. The governance problem is not convenience itself, but the visibility and review gap created outside SSO.
NHIMG editorial — based on content published by 1Password: OAuth login risk and visibility in SaaS environments
By the numbers:
- 27% of employees have used the same passwords for both their work and personal accounts.
Questions worth separating out
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.
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.
Q: What breaks when OAuth permissions are only reviewed manually?
A: Manual review breaks at scale because access changes faster than periodic audits.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
1Password's full article covers the operational detail this post intentionally leaves for the source:
- How Google Workspace app visibility works when teams need to identify OAuth-connected SaaS apps
- What 1Password SaaS Manager flags as risky permissions, including OAuth logins and read/write access
- How admins can export findings or revoke access directly from the dashboard
- Why business-led security workflows help teams contact employees about app need before access is removed
👉 Read 1Password's analysis of OAuth login risk and SaaS access visibility →
OAuth logins and shadow SaaS access: are your controls keeping up?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: OAuth login risk is still widening enterprise attack surface