OAuth 2.0 Explained: 8 Ideas That Keep Your Password Yours

by Souy Soeng /October 04, 2026

Diagram of OAuth 2.0: an app gets a limited access token from Google instead of the user's password

OAuth 2.0, explained simply, is the system that lets an app use part of your account, such as your calendar, without ever seeing your password. It runs behind every 'Sign in with Google' and 'Connect your account' button you have clicked.

An app asking for your Gmail password could be the worst click of your week. OAuth means you never have to type it in. Below are eight ideas, in the order they build on each other: the risk, the valet key, the four players, the flow, scopes, tokens, the identity twist, and the checks that keep you safe.

TL;DR

OAuth gives apps a limited token instead of your real password.
Scopes decide exactly what that token can and can't do.
Access tokens expire fast; refresh tokens quietly get new ones.
OAuth grants access; OpenID Connect proves who you are.
You can revoke any app's access at any time without changing your password.

1. Never hand an app your real password

Use this rule any time an app asks for your email login to 'sync' or 'organise' your stuff. Your email password is not just one key. When you forget a password for your bank, your social accounts or your cloud storage, the reset link lands in your inbox. Whoever controls your email can reset almost everything else. Email is the master key.

Type that password into a third-party app and the app has full control until you change it. It can read, send and delete. If that app gets hacked, your account goes down with it. This is not a rare edge case. Before OAuth, sharing your login was simply how one service talked to another.

Picture ten apps, each storing a copy of your real password on their own servers. That is ten places for your secret to leak, and you have no idea how well any of them protect it. Attackers don't target the strongest system. They find the weakest one. And in the old world, cutting off a single app meant changing your password everywhere.

Before OAuth: the app stores your password, gets full access, and one leak exposes it all.
With OAuth: the app never sees your password, gets only what you approve, and can be revoked on its own.
Verdict: your password belongs to you and the provider, nobody else.

2. Think of a token as a valet key

Use this picture whenever OAuth starts to feel abstract. Many cars come with a valet key. It starts the engine and drives the car to the parking spot, but it won't open the trunk or the glovebox. The valet gets exactly what they need and nothing more.

OAuth gives apps the same kind of key, called an access token. It unlocks only the specific things you approved. Calendar access? Fine. Your private emails stay locked, like the trunk. Your real key, your password, never leaves your pocket. You type it only on the provider's own page, such as Google's, never into the app.

That is OAuth in one sentence: apps get enough access to be useful, but never enough to take over. If you remember nothing else, remember the valet key and what it can't do.

Verdict: a token does one job, and your real key stays with you.

3. Meet the four players in every OAuth flow

Use these four roles to make sense of any 'Connect' screen. The official names sound intimidating, but the roles are simple: one owner, one visitor, one bouncer and one vault.

You are the resource owner, because it's your data: your photos, your calendar, your contacts. Nothing happens unless you say yes. The app is the client, for example a scheduling tool that wants to read your calendar. It has to ask permission and play by the rules to get it.

The authorization server is the bouncer. It checks your login, shows you what the app wants, and hands out tokens. For Google, that's accounts.google.com. The resource server is the vault. It holds your data and checks every token at the door before letting anything through.

Resource owner: you, the one who approves or denies.
Client: the app asking for access.
Authorization server: the bouncer that issues tokens.
Resource server: the vault that checks them.
Verdict: four roles, one handshake, and you hold the final say.

4. Follow the OAuth flow: redirect, approve, swap, access

Use these four steps to understand what happens in the seconds after you click 'Connect'. Step one: the app redirects you. Instead of showing its own password box, it sends your browser to the real login page, like Google's. That's your first safety check, because now you're on the provider's turf.

Step two: you approve. You log in on the provider's page and see a consent screen listing exactly what the app wants. Allow, or walk away. Step three: the swap. You're sent back to the app with a one-time code, and behind the scenes the app trades that code for an access token. Step four: the app shows its short-lived token to the resource server to get your data.

Under the hood, it's two simple web requests. The first is the redirect, which names the app through its client ID and the scope it wants, here just reading your calendar. The second is the app privately trading the one-time code for a token with an expiry time attached. At no point does your password travel to the app.

client_id: the app's name badge, shown to you on the consent screen. If the name looks wrong, stop.
scope: the exact permissions requested. Small scope, small risk.
The code: single-use and short-lived, swapped privately for the real token.
Verdict: your password never leaves the provider's page.

# 1. Send you to the login page
GET /authorize?client_id=sched-app
  &scope=calendar.read&response_type=code
# 2. Trade the code for a token
POST /token  code=xyz123
# Reply: access_token + expires_in

5. Check the scopes before you click Allow

Use scopes as your control panel every time a consent screen appears. Your whole account holds emails, files, contacts and more. The app requests a slice, you approve it, and the token it receives carries only that slice. A token with calendar read can look at your events, and that's all. It can't send email, delete files, or even edit the calendar. If it tries, the resource server says no.

Security folks call this least privilege: ask only for what you need. Good apps request the minimum. If a simple wallpaper app wants to read your contacts and send email, that's a giant red flag. Hit deny. You're no longer stuck choosing between everything and nothing.

Here's how it plays out with a scheduling app called Scheduly. You click Connect Google, land on accounts.google.com, and the consent screen says Scheduly wants to view your calendar. You allow it. Scheduly gets a one-time code, swaps it for an access token, and your events appear. It holds a read-only calendar pass. No password, no inbox, no Drive. If Scheduly gets hacked tomorrow, attackers get a limited pass that expires.

Read is not delete: a calendar-read token can't touch your email.
Too many scopes for the job is a reason to deny.
Verdict: you decide exactly how much each app can do.

6. Know your tokens: expire, refresh, revoke

Use this idea to understand why connected apps keep working without asking you to log in again. OAuth splits the job between two tokens. The access token does the work: it unlocks your data, travels with every request to the resource server, and expires fast. The refresh token fetches new access tokens, lasts longer until revoked, and goes only to the authorization server.

Why two? The token flying around constantly is the one most likely to leak, so it dies quickly. A stolen access token soon expires. Meanwhile the refresh token renews access in the background, so you aren't constantly logging in. Safety and convenience, split between two keys.

Every token has a life cycle. It's issued when you click Allow, often alongside a refresh token. It expires on schedule, often within an hour. The app refreshes it silently. And finally, you can revoke it: open your account's security settings, find the app, click remove. Its tokens stop working, your password stays the same, and your other apps keep running.

Access token: short-lived, does the work.
Refresh token: longer-lived, gets new access tokens.
Verdict: fast expiry limits damage, and revoking puts the off switch in your hands.

Use this distinction whenever you see 'Sign in with Google'. Most people think OAuth alone powers that button. That's only half true. OAuth is about authorization. It answers one question: what is this app allowed to do? An access token is like a hotel key card. It opens doors, but it doesn't say whose name is on the booking.

OpenID Connect handles authentication, meaning who you are. It sits on top of OAuth and adds an ID token that says, in effect, this is Sam, verified by Google. Picture a stack: OAuth in the middle handling permissions, OpenID Connect on top adding identity, and everything riding over encrypted HTTPS.

This matters most for developers. Treating a bare access token as proof of someone's identity is a classic bug. The token proves permission, not personhood.

OAuth: what is this app allowed to do?
OpenID Connect: who is this person?
Verdict: access and identity are different questions with different answers.

8. Avoid the four ways people get burned

Use this checklist every time a 'Connect' or 'Sign in with' button pops up. OAuth itself is solid. Trouble usually comes from rushed clicks, forgotten settings or careless code. Mistake one is clicking Allow without reading. The consent screen is your one chance to see what you're giving away. If a quiz app wants to send email on your behalf, stop.

Mistake two is falling for fake login pages. Scammers build pages that look exactly like Google's. Check the address bar before typing: accounts.google.com is real, a look-alike that swaps a letter or adds extra words is not. Mistake three is forgetting old apps. That game you connected years ago might still have access.

Mistake four is for developers: leaking tokens. Never put them in URLs, logs or public code. For everyone else, the habit is three quick checks: confirm the URL, match the scopes to the app's purpose, and review connected apps every few months. Revoking takes one click and breaks nothing else.

Check the URL before you type your password.
A photo editor needs your photos, not your contacts.
Spring-clean connected apps regularly.
Verdict: a few seconds of attention blocks most of these tricks.

The bottom line

Never give an app your real password.
OAuth hands apps a limited valet key: a token.
Scopes decide exactly what that token can do.
Access tokens expire fast; refresh tokens renew them.
OAuth is authorization; OpenID Connect handles identity.
You can revoke any app's access whenever you want.

Quick-fire questions

Does the app ever see my password with OAuth?

No. You type your password only on the provider's own login page, such as accounts.google.com. The app receives a one-time code and swaps it for a token, never your password.

What is the difference between an access token and a refresh token?

An access token unlocks your data and expires quickly, often within an hour. A refresh token lasts longer and is used only with the authorization server to get new access tokens, so you stay connected without logging in again.

Is 'Sign in with Google' the same thing as OAuth?

Not exactly. OAuth decides what an app is allowed to do, while OpenID Connect, built on top of OAuth, proves who you are with an ID token. 'Sign in with Google' relies on OpenID Connect for the identity part.

How do I remove an app's access to my account?

Open your account's security or connected apps settings, find the app, and remove it. Its tokens stop working, your password stays the same, and your other apps keep running.

What are OAuth scopes?

Scopes are the specific permissions an app requests, such as reading your calendar. The token it receives can do only what those scopes allow, so a calendar-read token can't send email or delete files.

How can I tell if a consent screen is safe?

Check that the address bar shows the real provider's domain, then check that the requested permissions fit the app's job. If anything looks off or the request is bigger than the task, deny it.

Watch the full video on YouTube →

Tag

Ad