Art of Code
Back to Blog
tutorials

OAuth 2.0 Explained in Plain English for Developers

OAuth 2.0 is what happens behind "Sign in with Google". Here is how it actually works, step by step, explained simply for developers.

Curious Adithya7 min read

You click "Sign in with Google". You get redirected. You approve something. You end up logged in.

What actually happened in those 3 seconds? That is OAuth 2.0. And once you understand it, you will never look at that button the same way again.

Why OAuth Exists

In the early internet, if you wanted one service to access your data on another service, you handed over your username and password. Literally. App B would log into App A as you.

That is terrifying. App B now has your credentials. It can do anything you can do. Change your password, delete your account, read private messages. And if App B ever gets hacked, your credentials are exposed on App A too.

OAuth 2.0 was built to solve this. Instead of sharing your password, you give a service a specific key that grants only the access you approve, and nothing more. You can revoke that key at any time without changing your password.

Think of it like a hotel key card. The card opens your room. It does not give the holder access to the safe, the minibar billing system, or the master key to the whole building. Limited access. Controlled. Revocable.

The Four Players in Every OAuth Flow

Every OAuth 2.0 interaction involves four parties. Know these and the rest makes sense.

Resource Owner. That is you. You own the data. Photos, emails, contacts, whatever it is, you are the one who decides who gets to access it.

Resource Server. The place where your data actually lives. Google Drive. Dropbox. A photo storage app. This server holds your stuff and will hand it over when presented with a valid access token.

Client. The third-party application that wants access to your data. A printing service, a productivity app, a dashboard tool. The client never gets your password. It gets a token.

Authorization Server. The gatekeeper. This server handles the OAuth process, verifies your identity, gets your consent, and issues the access token. It could be part of the resource server (Google's auth system handles both) or a separate service.

The OAuth Flow, Step by Step

Let me walk through this with a concrete example.

You use a photo storage app called Snap Store. You find a printing service called Print Magic that can pull your photos directly. You do not want to upload them manually. Here is what happens when you click "Connect to Snap Store" on Print Magic.

Step 1: Client requests authorization

Print Magic sends you to Snap Store's authorization server with two things: its client_id (identifying who Print Magic is) and a scope (what Print Magic is asking to access, like "read photos").

Step 2: You authenticate and consent

Snap Store shows you a screen. "Print Magic wants to read your photos. Allow?" You log in to Snap Store (if you are not already) and click Allow. You are the resource owner giving consent.

Step 3: Authorization code issued

The authorization server sends Print Magic a short-lived authorization code. This is not the access token yet. It is just proof that you said yes.

Step 4: Client exchanges code for access token

Print Magic takes that authorization code and, from its backend server, sends it to the authorization server along with its client_id and client_secret. The client secret is a private key only Print Magic and the authorization server know. It proves the request is coming from the real Print Magic, not some impersonator.

Step 5: Access token issued

The authorization server verifies everything, and if it all checks out, issues an access token to Print Magic.

Step 6: Client accesses your data

Print Magic uses that access token to request your photos from Snap Store's resource server. The resource server validates the token and hands over the photos.

Your Snap Store password was never shared with Print Magic. Not once.

You          Print Magic     Authorization Server     Snap Store
 |               |                    |                    |
 |---click----->>|                    |                    |
 |               |---auth request-->>|                    |
 |<<-----------redirect to auth server--------------------||
 |---login + consent--------------->>|                    |
 |               |<<-auth code--------|                    |
 |               |---code + secret->>|                    |
 |               |<<-access token-----|                    |
 |               |---access token---------------------->>|
 |               |<<-your photos----------------------------|

Why the Authorization Code Step Exists

You might wonder: why not just skip straight to the access token? Why issue an auth code first?

Because security.

The auth code is sent via the browser (front channel), which is less secure. The access token exchange happens server-to-server (back channel) using the client secret, which never touches the browser. This separation keeps the most sensitive part of the flow out of the browser where it could be intercepted.

This is called the Authorization Code Flow and it is the recommended flow for server-side applications.

Access Tokens and Refresh Tokens

Access tokens expire. Typically in minutes to hours. This is intentional. If a token gets stolen, the damage window is limited.

But you do not want your users to re-authorize an app every hour. This is where refresh tokens come in.

A refresh token is a longer-lived credential that the client can use to get a new access token without involving you. The flow is entirely backend. You stay logged in, the tokens rotate quietly in the background.

Refresh tokens themselves eventually expire too, or can be revoked. If you go to your Google account settings and click "Remove access" on a third-party app, you are revoking the refresh token. That app can no longer get new access tokens, even if it still holds an old expired one.

OAuth vs "Sign in with Google"

Quick note. OAuth 2.0 is specifically about authorization (granting access to resources). "Sign in with Google" is authentication (proving who you are). They are related but different.

The "Sign in with Google" button typically uses OpenID Connect, which is built on top of OAuth 2.0 and adds an identity layer. OAuth says "this app can read your calendar". OpenID Connect says "this is who you are".

But in practice, most developers encounter OAuth and OpenID Connect together, since both are involved in the "login with Google/GitHub/Apple" pattern.

What This Means For You as a Developer

If you are building an app that integrates with Google, GitHub, Twitter, Stripe, or basically any major API, you are using OAuth 2.0. Here is what you need to handle:

  • Register your app with the provider and get a client_id and client_secret
  • Define your scopes (only request what you actually need)
  • Implement the redirect flow (or use a library that handles it)
  • Store tokens securely (never in localStorage for sensitive apps, use httpOnly cookies)
  • Handle token refresh so users stay logged in without repeated prompts
  • Handle token revocation so users can disconnect your app from their settings

Most frameworks have libraries that handle the heavy lifting. In Next.js there is NextAuth. In Node.js there is Passport.js. These abstract the flow so you configure it rather than build it from scratch.

But knowing what is happening underneath makes you a better developer. When something breaks, you will know where to look.

What You Should Take Away

  • OAuth 2.0 solves the problem of letting apps access your data without sharing your password.
  • Four players: resource owner (you), resource server (your data), client (the app), authorization server (the gatekeeper).
  • The Authorization Code Flow: request authorization, get consent, receive auth code, exchange for access token, access the resource.
  • Access tokens expire. Refresh tokens let apps get new ones without re-asking you.
  • OAuth is authorization. OpenID Connect (built on OAuth) adds authentication.
  • As a developer, use trusted libraries for the implementation. Understand the flow so you can debug it.

OAuth 2.0 is everywhere. Every "Sign in with Google", every API integration, every third-party app permission screen. Understanding it is not optional anymore. It is foundational.

Written by Curious Adithya for Art of Code.