🔐Developer

OAuth 2.0 Explained Simply (Without the RFC)

OAuth confuses most developers the first time because the terminology obscures simple concepts. Here's what's actually happening when you 'Sign in with Google.'

6 min readFebruary 1, 2026By FreeToolKit TeamFree to read

When you click 'Sign in with Google,' a lot happens in about two seconds. Understanding what's happening demystifies OAuth and makes implementing it (or debugging it) much less painful.

The Core Problem OAuth Solves

Before OAuth, if a third-party app needed access to your data (say, a calendar app needing your Google Calendar), you'd give it your Google password. The app could then do anything with your Google account. OAuth was designed to solve this: grant limited, revocable access without sharing passwords.

The Four Actors in OAuth

Resource Owner: You (the user whose data is being accessed)
Client: The app requesting access (the calendar app)
Authorization Server: The entity that issues tokens (Google's auth server)
Resource Server: Where the actual data lives (Google Calendar API)

The Authorization Code Flow (What Actually Happens)

Step 1: Your app redirects you to Google with a request for specific permissions (scopes) and a random state value. Step 2: You log into Google and approve the permissions. Step 3: Google redirects back to your app with an authorization code. Step 4: Your app's backend exchanges that code for an access token (and optionally a refresh token). Step 5: Your app uses the access token to make API requests to Google.

Why the code exchange step? The authorization code travels through the browser (visible in the URL). Exchanging it for tokens happens server-to-server, keeping the actual tokens out of the browser. This is why the Authorization Code flow is more secure than the older Implicit flow.

Access Tokens vs Refresh Tokens

Access tokens are short-lived (minutes to hours) — they're what you use to make API calls. Refresh tokens are long-lived (days to months) and can request new access tokens when they expire. This limits exposure: if an access token leaks, it expires quickly. Refresh tokens should be stored securely and never exposed to the browser.

PKCE for Single-Page Apps

Single-page apps (React, Vue, Angular) can't safely store a client secret. PKCE (Proof Key for Code Exchange, pronounced 'pixy') solves this: the app generates a random code verifier, hashes it into a code challenge, and sends the challenge with the authorization request. When exchanging the code for tokens, the app sends the original verifier. The server verifies the hash matches. No client secret needed.

Generate secure tokens →

Frequently Asked Questions

What's the difference between authentication and authorization?+

Authentication is proving who you are (logging in). Authorization is determining what you're allowed to do (permissions). OAuth 2.0 is primarily an authorization protocol — it was designed to let users grant third-party apps limited access to their data without sharing passwords. The 'Sign in with Google' flow uses OAuth for authorization, then retrieves user identity information (authentication) as a secondary step. OpenID Connect (OIDC) is a thin identity layer built on top of OAuth 2.0 that standardizes the authentication part.

What's the difference between OAuth and JWT?+

OAuth is a protocol (a set of rules for how authorization works). JWT (JSON Web Token) is a token format. They're not alternatives — they're complementary. OAuth often uses JWTs as the access token format because JWTs are self-contained: the token itself encodes the user's permissions, so the server doesn't need to look up each request in a database. You can implement OAuth without JWTs, and you can use JWTs without OAuth. JWT is just a way to encode information into a token; OAuth is a framework for issuing those tokens.

Why should I use OAuth instead of building my own auth?+

Building authentication from scratch is genuinely hard to get right. Password hashing, salting, session management, CSRF protection, brute force mitigation, account recovery flows — each has subtle security requirements. Using OAuth with an established provider (Google, GitHub, Microsoft) means you're delegating that complexity to teams whose entire job is security. For applications where users have existing accounts with major providers, OAuth also reduces friction since users don't need to create yet another password.

Is OAuth secure? What are the common vulnerabilities?+

OAuth 2.0 is secure when implemented correctly. Common implementation mistakes: using the implicit flow (now deprecated in OAuth 2.1), not validating the state parameter (opens CSRF attacks), not validating the redirect_uri strictly (allows code interception), storing tokens in localStorage (vulnerable to XSS — use httpOnly cookies or memory). The Authorization Code flow with PKCE (Proof Key for Code Exchange) is the recommended secure implementation for most applications.

🔧 Free Tools Used in This Guide

Password Generator Hash Generator Jwt Decoder

FreeToolKit Team

We build free browser-based tools and write practical guides that skip the fluff.

Tags:

developersecurityauthenticationoauth

Continue Reading

🔐

Password Security in 2025: What Actually Matters

7 min read