A 30-staff financial advisory firm I worked with ran an internal audit of their OAuth grants last quarter. The IT lead exported the list of third-party apps authorised against the firm’s Google Workspace and Microsoft 365 accounts. The total came back at 412 active grants across the team. Forty-seven of those grants belonged to staff who had left the firm between 2023 and 2025. Three belonged to a contractor who had finished an engagement eighteen months earlier, and those three carried admin scope on the firm’s Google Drive. None of the leaver processes over the previous two years had triggered an OAuth revocation step.
The financial damage was zero, as far as anyone could tell from the access logs. The regulatory exposure was real. The compliance officer treated the finding as Schedule 7 material under the FCA SYSC operational-resilience rules. The cleanup took the IT lead and an external contractor a week of focused work. The owner’s reaction was the right one. OAuth had been doing exactly what it was designed to do, on every “sign in with Google” button across the firm, and nobody had been responsible for governing the trail it left behind.
What is OAuth?
OAuth is the authorisation standard that lets one application act on behalf of a user in another application, without sharing the password. The user clicks a button such as “Sign in with Google” or “Connect Slack”, a consent screen lists the specific permissions the app is requesting, and the user approves. The app receives a token from the identity provider, not a password, and uses that token to make scoped requests. The token can be revoked from the provider’s settings at any time, instantly, without the user changing their password or affecting any other connected app.
OAuth 2.0 is the dominant version in 2026 and is documented in IETF RFC 6749. OAuth 2.1, currently in draft, consolidates a decade of security best-practice guidance into a single specification. The mental model worth holding is that OAuth is delegation, not authentication. The user is delegating a narrow capability to a specific application, with scope, expiry, and a single-click revoke. Passwords and API keys do not offer any of those three properties, which is why OAuth has become the default for user-facing integrations.
Why does it matter for your business?
It matters because OAuth grants accumulate quietly across a firm, and almost nothing in a normal business process touches them. A 30-staff firm running Google Workspace, Microsoft 365, Slack, a CRM, and the usual marketing and finance tools will commonly carry 200 to 600 active OAuth grants across the team. Each one was authorised by an individual employee, in the moment, often inside the first week of using a new tool, and almost nobody can tell you a year later which ones are still in use or what scope they hold. That is fine until someone leaves, until a tool gets breached, or until a compliance officer asks for a list.
The Salesloft-Drift breach in August 2025 showed the modern shape of the risk. Attackers compromised Salesloft’s infrastructure, stole the OAuth tokens it held for its Salesforce integration, and used those tokens to reach Salesforce data across more than 700 customer organisations. The tokens were legitimate. They bypassed passwords and multi-factor authentication entirely, because that is what OAuth tokens do once issued. The customers who recovered fastest were the ones who already knew which OAuth grants their organisation held, because they could revoke the right one in minutes. The customers without an inventory took days to work out what to disconnect.
Where will you actually meet it?
You meet OAuth in five places any UK SME owner will recognise. Google Workspace OAuth is the canonical “sign in with Google” and the way SaaS tools connect to Drive, Calendar, and Gmail. Microsoft Entra ID handles the same role across the M365 stack, with admin-consent and verified-publisher controls in the admin centre. Slack OAuth runs every app in the Slack marketplace, with the workspace admin able to see scope and audit installations. GitHub OAuth governs developer-tool access to repositories. Stripe Connect uses OAuth so a marketplace platform can manage seller payouts without holding seller credentials. The differences mainly matter at admin level, not at integration code itself.
The leaving-employee problem is where SMEs commonly get hurt, and it is structural rather than negligent. When an employee leaves, account deactivation and password rotation usually happen on the day. OAuth revocation rarely does, because grants are scoped per app per user and there is no single button in any provider that says “revoke everything this user ever authorised.” The result is a long tail of valid tokens still acting in the leaver’s name, against tools the firm may not know are connected. NCSC guidance treats this as a baseline control, ICO accountability under UK GDPR Article 5(2) expects you to demonstrate it, and FCA-regulated firms must track it under SYSC.
When to ask vs when to ignore
The threshold to take OAuth governance seriously is the moment a firm has more than ten staff, any regulatory exposure, or any tool that touches personal data. At that point the 2026 pattern is straightforward and cheap. Run a quarterly OAuth audit by exporting the grants list from Google Workspace, Microsoft Entra ID, and Slack, and review by app and user. Add an OAuth revocation step to the leaver checklist, alongside account deactivation and password reset. Review scope requests when a new tool connects for the first time, and push back on excessive scopes before any user authorises. The whole programme is a spreadsheet, a checklist line, and an hour or two a quarter, owned by one named person.
You can skip the formal programme if you are a one or two-person firm with no personal data flowing through your stack and a handful of tools you set up yourself. At that scale, a single OAuth review when you change roles or wind a tool down is enough. The mistake is the assumption that low headcount means low exposure. A 5-staff firm running a CRM with read-write access to client emails, a marketing tool with broad Drive scope, and a contractor’s old Slack grant carries the same shape of risk a 30-staff firm has, just on a smaller surface. The procurement question worth asking every vendor is the same. What scopes does your app request and why, how long are the tokens valid, and how do we revoke for a single user from our admin console rather than a support ticket? Vendors with mature OAuth handling answer cleanly. Those who deflect are giving you procurement information, just not the kind they intended.
Related concepts
An API key is the closest sibling concept and the useful contrast. API keys authenticate an application to a vendor as a single static credential, with no per-user scope and no easy per-user revocation. OAuth tokens authenticate an application acting as a specific user, with scope, expiry, and a single-click revoke. Both have legitimate roles, API keys for backend service-to-service calls, OAuth for any integration acting on behalf of a person. Knowing which one a vendor is offering is the first procurement question after “do you have an API.”
An API is the interface itself, the set of endpoints a vendor exposes for software-to-software calls. OAuth is one of the authentication models that sits in front of that interface when the call is acting as a user. A webhook is the inverse direction, the vendor pushing events to a URL you provide, often secured with a signing secret rather than OAuth. MCP is the 2026 standard for letting AI agents discover and call tools, and it leans on OAuth for any user-acting flow inside that pattern.
OAuth is the quiet workhorse of every modern tool integration, and the failures are governance failures rather than protocol failures. If you want a second pair of eyes on your firm’s OAuth inventory or what to ask your vendors next, book a conversation.
