OAuth Explained: Delegated Access Without Sharing Passwords

You've used it a hundred times: an app says "Connect your Google account" or "Sign in with GitHub," and somehow it gains access to your data without you typing your Google password into it. That's OAuth — the standard for granting one application limited access to your data on another service, safely. It's one of the most important and most misunderstood protocols in auth, so let's build it up from the problem it solves.

The problem: never share your password

Imagine a photo-printing app that wants to access your Google Photos. The naïve, dangerous way: you type your Google password into the printing app, and it logs in as you.

The core insight of OAuth is delegation: you should be able to grant an app limited, specific, revocable access without ever giving it your credentials.

How OAuth works: the delegated flow

Instead of the app handling your password, OAuth routes you through the real service to approve access. The roles, in plain terms:

• You — the resource owner (it's your data).
• The app — wants access (the "client").
• The service — holds your data and your account (e.g. Google).

The crucial move: you authenticate with Google directly, on Google's own page — the app never sees that step. After you approve, Google hands the app an access token. Your password never touches the third-party app at any point. The app walks away with a token, not your credentials.

Scopes: granting only what's needed

OAuth grants aren't all-or-nothing. Scopes define exactly what the app is asking permission to do, and you consent to that specific list:

This is least privilege in action. The printing app asks only to read your photos, and that's all it can do — it can't post, delete, or read your email, because you never granted those scopes. The consent screen you see ("This app wants to: view your photos") is OAuth showing you the exact scopes before you agree.

Access tokens: acting on your behalf

After consent, the app holds an access token — a credential representing the specific permission you granted. The app includes this token on its requests to the service, which checks it and allows exactly the scoped actions.

The token is powerful but bounded: it works only for the scopes you approved, it's tied to your grant, and — crucially — you can revoke it. Go into your Google account's "connected apps," remove the printing app, and its token stops working. You revoke one app's access without affecting anything else or changing your password. That revocability is a direct answer to the password-sharing disaster we started with.

OAuth is authorization, not authentication

Now the single most important clarification, the one that trips up nearly everyone:

So how do all those "Sign in with Google" buttons work, if OAuth isn't for login? They use a thin identity layer built on top of OAuth — which is exactly the subject of the next chapter.

Recap

• OAuth lets you grant an app limited access to your data on another service without sharing your password.
• It solves the disaster of typing your password into third-party apps, replacing it with a safe, scoped, revocable grant.
• You approve access at the real service; the app receives an access token, never your credentials.
• Scopes make permission granular — the app gets exactly what you consented to, and nothing more.
• OAuth is authorization, not authentication — it grants access, but doesn't by itself prove who you are.

OAuth grants access but doesn't prove identity. The layer that adds "who is this user?" on top of OAuth is OpenID Connect — what actually powers "Sign in with Google." Continue to OpenID Connect.