Key Takeaways
- What is OAuth? A protocol that lets you grant an app access to your data on another service, without giving it your password.
- Login with Google: Uses OAuth 2.0 + OpenID Connect. Google verifies you, then sends the app a token representing your identity and permissions.
- Your password stays safe: The app never sees your Google (or GitHub, or Apple) password. That is the whole point of OAuth.
- Scopes: The specific permissions the app requests. You approve them on Google's consent screen before access is granted.
You click "Login with Google" and you are in. But your Google password never went to the app you just logged into. How? That is OAuth — one of the most elegantly designed security protocols in modern software, and one that almost no one outside of security and development teams can fully explain.
You have used OAuth hundreds of times. Every social login button — Login with Google, Login with GitHub, Login with Apple — is OAuth. Understanding how it actually works gives you a clearer picture of internet security and is essential knowledge for any developer building applications with user authentication.
The Problem OAuth Solves
OAuth solves the problem of third-party access to your accounts without credential sharing. Before OAuth, apps that wanted to access your data on another service asked for your username and password for that service. You gave Yelp your Google credentials so it could find you on Google. This was terrible — the app now had your password and could do anything with it.
The "valet key" analogy is apt: a valet key for a car lets the valet drive your car to the parking spot but does not unlock the trunk or the glove compartment. OAuth is a valet key for your digital accounts — it grants limited, specific access without giving away the master key (your password).
What OAuth Actually Is
Learn the Core Concepts
Start with the fundamentals before touching tools. Understanding why something was built the way it was makes every tool decision faster and more defensible.
Build Something Real
The fastest way to learn is to build a project that produces a real output — something you can show, share, or deploy. Toy examples teach you the happy path; real projects teach you everything else.
Know the Trade-offs
Every technology choice is a trade-off. The engineers who advance fastest are the ones who can articulate clearly why they chose one approach over another — not just "I used it before."
Go to Production
Development is the easy part. The real learning happens when you deploy, monitor, debug, and scale. Plan for production from day one.
OAuth 2.0 is an authorization protocol — a defined set of rules for how one application can request and receive permission to access a user's data on another service. It involves three parties:
- Resource Owner: You — the person who owns the data.
- Resource Server: The service that has your data (Google, GitHub, etc.).
- Client: The application requesting access to your data.
OAuth defines how the client asks for access, how you as the resource owner grant or deny it, and how the resource server issues tokens that the client can use. The resource owner (you) remains in control — you can revoke access at any time.
The OAuth Flow: Step by Step
Here is exactly what happens when you click "Login with Google" on a third-party app.
- You click the button. The app (client) constructs a URL to Google's authorization server with parameters including: what app is requesting, what permissions (scopes) it needs, and where to redirect after authorization.
- You are redirected to Google. Your browser goes to Google's login page. If you are already logged in, you may skip re-entering credentials.
- Google shows a consent screen. "App XYZ wants to: See your name, email address, and profile photo." You click "Allow" or "Deny."
- Google redirects you back with a code. If you approved, Google redirects your browser back to the app with a short-lived authorization code in the URL.
- The app exchanges the code for tokens. The app's server sends the authorization code back to Google along with a client secret (proof the app is who it claims to be). Google returns an access token and optionally a refresh token.
- The app uses the access token. The app sends the access token to Google's API to retrieve your profile information. Google verifies the token and returns the data.
At no point did your Google password leave Google. The app received only what you approved: a token representing your consent for the specific scopes requested.
Access Tokens Explained
An access token is a credential that represents a user's granted permissions to a specific application for a limited time. It is a string (typically a JWT) that the app presents to the resource server to prove it has been authorized to access certain data.
Access tokens are short-lived by design — typically 1 hour. After expiration, the app needs a new one. If the user revokes access, the token becomes invalid immediately. This limits the damage window if a token is intercepted.
Refresh tokens are longer-lived credentials that allow the app to obtain new access tokens without requiring the user to re-approve. They are stored server-side and never exposed to the browser.
Scopes: What the App Can Access
Scopes are the specific permissions an OAuth authorization request includes. When you see a consent screen listing what an app wants to access, you are seeing the scopes that app requested.
For Google, common scopes include:
openid— Use OpenID Connect to verify your identityemail— See your email addressprofile— See your name and profile picturehttps://www.googleapis.com/auth/calendar.readonly— Read your calendar eventshttps://www.googleapis.com/auth/gmail.send— Send email on your behalf
Reputable applications request the minimum scopes they need. If an app asks for Gmail send permission when it only needs your name and email for login, that is a red flag. Always read consent screens and question requests for permissions beyond what the app's function requires.
OAuth vs OpenID Connect
OAuth 2.0 handles authorization (what can the app access?). OpenID Connect (OIDC) adds authentication (who are you?) as a layer on top of OAuth.
In pure OAuth, the app gets permission to access your data but has no formal way to know who you are. OpenID Connect fixes this by adding an ID token — a JWT that contains your identity information (name, email, unique user ID) — alongside the access token. Most "Login with X" implementations use OpenID Connect, not just OAuth.
The practical distinction: when you see "Login with Google," OpenID Connect is verifying your identity. When an app says "Connect your Google Calendar," that might be pure OAuth to get calendar access without necessarily needing to know who you are.
Security Considerations
OAuth is well-designed, but it can be implemented poorly. Key security considerations:
- Always use HTTPS. OAuth tokens transmitted over HTTP are interceptable. This is non-negotiable.
- Validate the state parameter. OAuth flows use a "state" parameter to prevent cross-site request forgery (CSRF). Apps that skip state validation are vulnerable.
- Use PKCE for public clients. Mobile and single-page apps cannot keep client secrets. PKCE (Proof Key for Code Exchange) is the standard extension that protects these flows.
- Store tokens securely. Refresh tokens should never be stored in browser localStorage. Use httpOnly cookies or secure server-side storage.
- Minimal scopes. Request only the permissions you need. Excess scope is unnecessary risk exposure.
Build secure apps with auth that works. Learn in person.
The Precision AI Academy bootcamp covers authentication, APIs, and building production AI applications. $1,490. October 2026.
Reserve Your SeatFrequently Asked Questions
What is OAuth?
OAuth (Open Authorization) is an open standard protocol that allows applications to access a user's data on another service without the user giving their password to the requesting application. It is the protocol behind Login with Google, Login with GitHub, and any other social login button.
How does Login with Google actually work?
When you click Login with Google: (1) the app redirects you to Google's authentication server; (2) Google shows you a consent screen; (3) if you approve, Google redirects you back with an authorization code; (4) the app exchanges the code for an access token; (5) the app uses the access token to request your profile from Google's API. Your Google password never touches the app's servers.
What is the difference between OAuth and OpenID Connect?
OAuth 2.0 is an authorization protocol — it controls what an application can access on your behalf. OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0 — it adds identity verification, telling the app who you are. Most Login with Google implementations use OpenID Connect, which uses OAuth 2.0 for authorization and adds an ID token with your identity information.
Is OAuth the same as an API key?
No. An API key is a static credential that identifies an application. OAuth is a flow that involves a user granting temporary, scoped permissions to an application to access their data. API keys do not expire and do not involve user consent; OAuth tokens are temporary and represent a specific user's granted permissions.
What are OAuth scopes?
OAuth scopes are the specific permissions an application requests. The consent screen shows users exactly what scopes are being requested. Apps should request only the permissions they actually need — excess scope requests are a security concern and an indicator of poor implementation or suspicious intent.