You have tapped "Sign in with Google" on dozens of apps. Notion. Spotify. Some project management tool you tried once. You never typed your Google password into any of them. That is not a coincidence. It is a protocol called OAuth, and once you understand how it works, you will never click that Allow button the same way again.
The problem OAuth was built to solve
In the early days of connected web apps, "integrating with your Google account" often meant handing an app your actual Gmail credentials. The app would log in on your behalf, pull whatever it needed, and store your username and password somewhere on its servers.
This was obviously terrible. You could not audit what the app was doing with your account. You could not revoke access without changing your password. If the app's servers were breached, attackers walked away with your Google login. Yelp, LinkedIn, and dozens of other services built features this way in the mid-2000s, and users had no real way to know the risk they were accepting.
OAuth (Open Authorization) was published as an open standard to fix this architecture. The current version, OAuth 2.0, landed in 2012 and is now the foundation of nearly every "sign in with" button on the internet.
Three parties, one silent deal
Every OAuth exchange involves exactly three actors, and the protocol only works because all three play their defined role.
The user: you, clicking the button.
The identity provider: the service you already trust. Google, Microsoft, GitHub, Apple. You have an account there, and you have already established a relationship with them.
The app: the service requesting access to something in your name. It wants to read your calendar, or post to your account, or see your email address.
The analogy I keep returning to is a hotel. You are the guest. You ask the front desk to cut a keycard for a contractor who needs one-time access to your room. The contractor never learns your room PIN or the master code. The keycard opens that one door, for that one window of time, for exactly the access you authorized. That is the mental model. The app is the contractor. Google is the front desk. You are the guest who decides what the keycard opens.
What you are actually approving when you click Allow
Before OAuth hands anything to the app, Google shows you a list. Most people click through it in under two seconds. That list is not decoration. Each item is a "scope": a specific, bounded permission the app is requesting from your account.
"View your basic profile information" means your name and profile photo. That is a narrow scope. The app gets just enough to show your name in its interface.
"See your primary Google Account email address" means just the address, not the contents of your inbox.
"Manage your email" means read, compose, send, and delete. That is a completely different key. An app with manage-email scope can do anything in your inbox for as long as you have not revoked it.
The consent screen exists precisely so you can make this call. Read it before you click. It genuinely takes fifteen seconds, and the permissions are real and persistent once granted. A calendar-management app asking for email-delete scope is a yellow flag worth noticing.
The token, not the password
After you approve, Google does not send your password to the app. It generates an access token: a long, unique string that acts as a scoped credential for exactly the permissions you just approved.
The app holds this token and uses it to make API calls on your behalf. "Give me the files in Felix's Google Drive marked shared." Google checks the token, verifies the scope covers Drive access, returns the files. Your password never appears in this exchange.
This matters most when things go wrong. If the app is breached tomorrow and an attacker steals the stored token, they get access to what the scope allows and nothing more. They cannot log into your Google account. They cannot reset your password. They cannot pivot to other Google services outside that scope. Revoke the token, and the access is gone immediately. No password reset needed anywhere.
The risks that remain
OAuth is architecturally safer than password sharing, but two risks stay real.
First: your identity provider's security is now the single most important variable. If your Google account is compromised through a weak password or a successful phishing attempt, every app with an active OAuth token to that account is exposed too. The token lives downstream of your account. Protecting your Google or Microsoft login with a strong, unique password and MFA matters more than ever, precisely because so much else depends on it.
Second: tokens accumulate quietly. You click Allow on a dozen apps over three years, forget most of them, and leave tokens active for services you have not used since the last time you tried a productivity app. This is a real attack surface. Audit it. Google makes it straightforward at myaccount.google.com/permissions. Microsoft 365 has an equivalent under My Applications. Remove anything you do not recognize, do not actively use, or that is requesting broader scopes than it needs. Five minutes, once a year.
How this shows up in my actual work
Most of the integrations I build run on OAuth: an n8n workflow connecting to Google Sheets, Power Automate reading from SharePoint, Zapier monitoring an Outlook inbox for automated routing. Nobody types a password into any of these. Each connection holds a scoped token tied to a service account provisioned with exactly the permissions the workflow needs.
When someone leaves a company, one of the first steps in my offboarding runbook is to revoke that account's OAuth tokens. Not just disable the Active Directory login, which some teams treat as the complete offboarding action. A disabled account does not automatically invalidate tokens that third-party apps have already stored, especially if those apps authorized against a personal Google workspace rather than the corporate identity provider. Revoke the tokens explicitly. Check both Google and Microsoft tenant-level app authorizations.
This is the kind of thing that stays invisible until someone discovers a departed employee's Zapier connection is still reading the company calendar eighteen months after they left. Understanding the protocol is what lets you close that gap before the audit does.
Sources
OAuth 2.0 specification, oauth.net (the canonical reference for the protocol itself)
Google Account: Third-party apps with account access
Microsoft My Applications portal
Questions about OAuth in your stack, or want to talk through how it applies to your team's tooling? Reach out here.
Comments