OAuth 2.0 Basics

You’ve seen this button everywhere, right? You land on some new app, and instead of asking you to make a fresh account, it just says “Log in with Google”:

• You click it, a Google screen pops up, you say yes, and boom, you’re in.
• But here’s the wild part. You never typed your Google password into that new app.
• And yet, somehow, the app now knows your name and email. How does that even work?

That magic button is powered by something called OAuth 2.0. So let’s slow down and see exactly what’s going on behind it.

🎯 The Problem

Let’s picture a real situation. Say you’ve got a photo printing app, and you want it to grab your photos straight from your Google account so you don’t have to upload them one by one:

• The printing app needs to reach into your Google Photos and pull out your pictures.
• The easy-but-terrible way would be to just hand the app your Google email and password.
• But think about what that means. Now that app can read your Gmail, see your contacts, delete your stuff, change your password. It can do anything you can do.

That’s way too much power to give some random app just so it can print a few photos, right? So here’s the real question this whole topic answers:

• How do you let App B use some of your data from App A?
• Without ever giving App B your password?
• And in a way where you can take that access back later if you change your mind?

🔑 What is OAuth 2.0

OAuth 2.0 is the standard way to solve exactly that problem. Let’s define it clearly:

• OAuth 2.0 is an authorization framework. An authorization framework is just an agreed-upon set of rules that lets one app get limited access to your account on another service.
• The key trick is this. Instead of giving the app your password, the app gets a token. A token is a short string that acts like a temporary pass, saying “the owner allows this much access, for now.”
• So the app uses that token to do its job, and it never sees your actual password. Not even once.

Here’s the one line to burn into your memory. OAuth is about authorization, not authentication:

• Authorization means deciding what someone is allowed to do. Like “this app may read your photos.”
• Authentication means proving who you are. Like logging in to confirm you’re really you.
• OAuth’s main job is that first one, allowing access. We’ll come back to this difference later because it trips up almost everyone.

🧩 The Players

OAuth has four roles in the story, and once you know who’s who, the whole thing clicks. Let’s meet them using our photo printing example:

• Resource owner is you. You’re the one who owns the data (your photos) and gets to say who can touch it.
• Client is the app that wants access. Here it’s the photo printing app. “Client” just means the app making the request, nothing fancy.
• Authorization server is the one that checks with you and hands out tokens. For Google data, this is Google’s login system.
• Resource server is where your actual data lives. Here it’s Google Photos, the place the client will call to fetch your pictures.

Here’s the same thing laid out side by side so it’s easy to keep straight.

⚙️ The Basic Flow

Now let’s walk the whole thing start to finish. You’re on the photo printing app and you click “Connect Google Photos.” Here’s what happens:

• You click the connect button on the client (the printing app).
• The app sends you over to the authorization server, which is Google’s login page. This is called a redirect, meaning the app just points your browser somewhere else.
• Google shows you a screen that says something like “Photo Printer wants to view your photos. Allow?” You read it and you approve.
• Google then issues an access token and hands it back to the app. An access token is that temporary pass we talked about, a short string the app shows to prove it’s allowed in.
• Now the app uses that token to call the resource server (Google Photos) and pull only your photos. Nothing else.

Two terms to lock down from that flow:

• An access token is the temporary key the app uses to make requests. It carries the permissions you approved, and it usually expires after a while.
• A scope is the specific permission being asked for, like “view photos.” We’ll dig into scopes next, since they’re what keeps the access limited.

Here’s the flow as a picture. Notice how the password never leaves Google.

🎯 Scopes

So how does Google know the app should only see photos and not your email? That’s what scopes are for. Let’s define it:

• A scope is one specific permission the app is asking for. Things like “read your email” or “view your photos” or “see your basic profile.”
• When the app sends you to the approval screen, it lists the exact scopes it wants. That’s why the screen says “wants to view your photos” and not just “wants access.”
• The access token you get back is stamped with only those scopes. So the app can do those things and literally nothing more.

Why this matters so much:

• Scopes keep access narrow. The printing app asks for photos, so it gets photos, and it can’t go poking around your inbox.
• You can see exactly what you’re agreeing to before you click approve. No surprises.
• It follows a good security habit called least privilege, which just means give an app the smallest amount of access it needs to do its job, and nothing extra.

🆚 OAuth vs Login

Okay, so if OAuth is about authorization, then what’s actually happening when you “Sign in with Google” to log into an app? Good question. Let’s untangle it:

• Plain OAuth 2.0 is about delegated access. “Delegated” means you’re handing off a slice of your permissions to an app. So OAuth gives the app a token to do things with your data.
• But logging in is a different need. The app doesn’t want to do things, it just wants to know who you are so it can let you into your account.
• For that, there’s a layer built on top of OAuth called OpenID Connect, often shortened to OIDC. OpenID Connect adds identity on top of OAuth, so the app gets a verified answer to “who is this person?”

So the short version is this:

• OAuth 2.0 by itself handles authorization, letting an app access your data.
• OpenID Connect sits on top and handles authentication, telling the app who you are.
• “Sign in with Google” uses both together. That’s why it can log you in and know your name and email.

⚠️ Common Mistakes and Misconceptions

A few ideas trip people up constantly. Let’s clear them out one by one:

• “OAuth is authentication.” Not really. OAuth 2.0 is about authorization, deciding what an app may access. The login part comes from OpenID Connect layered on top, not from OAuth itself.
• “The app sees your password.” It never does. You type your password only on the authorization server’s own page (like Google’s). The app only ever gets a token.
• “Tokens never expire.” They do, and that’s a good thing. Access tokens usually expire after a short time, so even if one leaks, it stops working soon. That’s a feature, not a bug.

🛠️ Design Challenge

Try this on your own to test yourself.

Imagine you’re building a calendar app, and you want it to read events from a user’s Google Calendar so it can show them in one place. Walk through the OAuth flow for it:

• Who is the resource owner, the client, the authorization server, and the resource server here?
• What single scope would you ask for, and why just that one?
• Where exactly does the user type their password, and where do they not?

Write down your answers, then check them against the four roles and the flow above. If you can narrate this cleanly, you’ve got OAuth.

🧩 What You’ve Learned

You can now explain how that “Log in with Google” button actually works. Here’s what you’ve picked up.

• ✅ OAuth 2.0 lets an app get limited access to your data on another service, without ever seeing your password.
• ✅ The app gets an access token instead, a temporary pass that carries only the permissions you approved.
• ✅ There are four roles: resource owner (you), client (the app), authorization server (issues tokens), and resource server (holds your data).
• ✅ Scopes keep access narrow, so the app can only do the specific things you agreed to.
• ✅ OAuth handles authorization, not authentication. OpenID Connect adds login on top.
• ✅ Tokens expire and can be revoked, which limits the damage if one ever leaks.

🧠

Check Your Knowledge

Test what you learned. Pick an answer for each question, then click Check.

1. 1

   What problem does OAuth 2.0 solve?

   Encrypting traffic between a browser and a server Letting one app get limited access to your data on another service without giving it your password Speeding up how fast a website loads Storing passwords safely in a database
   Check

   Why: OAuth lets App B use some of your data from App A through a token, so you never hand over your password.

2. 2

   In OAuth, who is the resource owner?

   The app that wants access You, the person who owns the data and grants permission Google's login system The server where the data lives
   Check

   Why: The resource owner is you; the client is the app, the authorization server issues tokens, and the resource server holds your data.

3. 3

   What does a scope do in OAuth?

   It encrypts the access token It limits the access to one specific permission, like 'view your photos' It stores your password on the client It makes the token last forever
   Check

   Why: A scope is one specific permission the app asks for, so the token grants only that and nothing more.

4. 4

   Is OAuth 2.0 about authentication or authorization?

   Authentication, because it proves who you are Authorization, because it controls what an app can access Neither, it only encrypts data Both equally, with no extra layer needed
   Check

   Why: OAuth handles authorization; 'Sign in with Google' adds OpenID Connect on top to handle the authentication part.

Score: 0 / 4 Reset

🚀 What’s Next?

You’ve got the foundation now. Next, go deeper into the ideas OAuth builds on.

• Authentication vs Authorization clears up the difference between proving who you are and what you’re allowed to do.
• API Security shows how tokens, keys, and access controls keep your APIs safe in the real world.

Get those down, and you’ll have a solid grip on how modern apps share data safely without passing passwords around.