What is OAuth?

Every time you click "Sign in with Google" or "Connect your GitHub account," you are using OAuth. You have used it hundreds of times. Most developers have implemented it at least once. And the April 2026 Vercel breach, which exposed credentials for hundreds of organizations, happened because of a single misconfigured OAuth permission.

That is worth understanding properly.

The Problem OAuth Solves

Before OAuth existed, the common way to let a third-party app access your data was to give it your password. You wanted a calendar app to read your Gmail? Hand it your Google credentials. You wanted a dashboard tool to pull your GitHub issues? Give it your GitHub username and password.

That is a disaster. The third-party app now holds credentials that access everything in your account, not just the calendar or the issues. If that app gets breached, your entire account goes with it. If you want to revoke access, you have to change your password, which cuts off every other service using it too.

OAuth solves this by separating authentication from authorization. You authenticate directly with the service that holds your data (Google, GitHub, wherever). That service then issues a token to the third-party app. The token represents permission to do specific things, nothing more. The third-party app never sees your password.

How OAuth Actually Works

The flow has four main actors. The resource owner is you. The resource server is where your data lives (Gmail, GitHub, Slack). The client is the third-party app that wants access. The authorization server is the service that issues tokens, usually the same company as the resource server.

When you click "Connect with GitHub" on some dev tool, here is what happens:

The client redirects you to GitHub's authorization server with a request that specifies what permissions it needs. GitHub shows you a screen listing those permissions and asks if you want to grant them. You say yes. GitHub generates an authorization code and sends you back to the client with it. The client exchanges that code for an access token by making a server-to-server request to GitHub. GitHub issues the token. The client stores it and uses it to make API calls on your behalf.

The access token is what the third-party app presents with every request. It is not your password. It has a defined scope, a defined expiry, and GitHub can revoke it at any time without touching your account credentials.

That scope is where things get dangerous.

OAuth Scopes and Why "Allow All" Is a Loaded Gun

Scopes define what a token can actually do. A token with the read:user scope on GitHub can read your profile. A token with repo scope can read and write to repositories. A token with admin:org can administer your entire organization.

When an app requests permissions, it asks for specific scopes. Responsible apps ask for the minimum they need. Irresponsible apps ask for everything, either out of laziness or because their feature set genuinely touches many parts of the API.

The problem is users. When a productivity app presents an OAuth consent screen and says "this app wants access to: your email, your calendar, your contacts, your drive files, and the ability to act on your behalf," most users click accept without reading it. Enterprise users with corporate accounts do this too. They want the tool to work. They do not think about what they just handed over.

In the Vercel breach, a Vercel employee used their enterprise Google Workspace account to sign up for Context.ai's Office Suite, a consumer productivity tool. The OAuth grant was broad. When the attacker compromised Context.ai's OAuth infrastructure and got access to stored tokens, that single "Allow All" grant became the key to a Vercel employee's corporate Google Workspace. From there, the attacker moved into Vercel's internal environments.

The OAuth token did exactly what it was supposed to do. It granted access. Nobody checked whether a consumer app should have that kind of access to an enterprise account.

The Token Theft Attack

OAuth tokens are bearer tokens. Whoever holds the token gets the access. There is no additional check that the holder is the original owner. If an attacker steals your access token, they can make API calls as you until the token expires or gets revoked.

Infostealers harvest tokens along with everything else. The Lumma Stealer malware that infected the Context.ai employee's machine in February 2026 pulled session cookies, saved credentials, and tokens from the browser and any locally stored app data. Those tokens went into an exfiltrated log file. The attacker then had live, working tokens for whatever services that employee was authenticated to.

This is why token rotation matters. Short-lived tokens reduce the window an attacker has to use a stolen credential. Refresh tokens add a layer, but they can also be stolen. The fundamental issue is that a stolen token looks identical to a legitimate one from the resource server's perspective.

Enterprise OAuth Controls That Should Have Caught This

Google Workspace gives administrators significant control over what OAuth apps users can authorize. Administrators can:

• Restrict which apps users can authorize, limiting it to apps that Google has reviewed or apps the organization has explicitly approved
• Block users from authorizing apps that request risky scopes
• Require admin approval before any new OAuth app gets access to organizational accounts
• Set up alerts for new OAuth authorizations to organizational accounts
  Most enterprises use some of these controls. Vercel did not have them configured tightly enough to catch a consumer app being authorized with "Allow All" permissions on an enterprise account. That is the real gap. Not the existence of OAuth. The absence of the controls that exist specifically for this scenario.

If you run Google Workspace for any organization, go to your admin console and check what third-party apps have OAuth access right now. The list will probably surprise you. Check for the Vercel IOC while you are there: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com.

OAuth Versions: 1.0 vs 2.0

OAuth 1.0 used cryptographic signatures. Every request was signed with a secret key, which meant even if someone intercepted the request, they could not replay it or forge new ones. The tradeoff was complexity. Implementing OAuth 1.0 correctly required careful handling of the signature process.

OAuth 2.0 dropped the signature requirement in favor of HTTPS for transport security. This made it dramatically simpler to implement and adopt. It also shifted more of the security burden onto correct token handling. With OAuth 1.0, a leaked token was less useful without the signing key. With OAuth 2.0, a leaked token is immediately usable.

Most services use OAuth 2.0 today. The security model depends on HTTPS being correctly enforced end-to-end and on tokens being stored and transmitted securely. When those assumptions break, or when tokens end up in infostealer logs, the simplicity of OAuth 2.0 becomes a liability.

What Developers Should Do

If you are building an application that uses OAuth:

Request the minimum scopes your application actually needs. If you need to read a user's profile name, ask for read:user, not admin:org. Document why you need each scope and revisit it when the application changes.

Use short-lived access tokens with refresh tokens rather than long-lived tokens. A 15-minute access token with a refresh token rotation policy limits the window an attacker has with a stolen credential.

Store tokens securely. Do not log them. Do not put them in environment variables that end up in build logs. Do not store them in localStorage on the frontend without understanding the XSS implications. Treat them exactly like passwords.

Implement token revocation for your users. If a user reports suspicious activity or wants to disconnect your app, you should be able to revoke their tokens immediately.

If you are a user or an enterprise administrator:

Audit your OAuth connections regularly. Every major service has a settings page showing which apps have access to your account. Go look at it. Revoke anything you do not recognize or no longer use.

As an administrator, enable the Google Workspace controls that require app approval before users can authorize new OAuth applications. The friction is minor. The protection is significant.

Related reading from the CoderOasis library: The Vercel breach is the direct example of OAuth misuse at enterprise scale. The What is Supply Chain Security article covers the broader attack pattern. And the What is Encryption breakdown explains why Vercel's sensitive environment variable feature actually protected users whose secrets were properly stored.