OAuth 2.0 Explained: How 'Login with Google' Works

You've probably used OAuth 2.0 today without realizing it. Every time you click "Login with Google," let an app access your calendar, or connect a tool to your GitHub account, you're relying on this framework behind the scenes.

OAuth 2.0 has become the standard for delegated authorization across the web. According to RFC 6749, it lets apps request limited access to a user's resources on another service — all without the user sharing their password. Despite its wide use, many developers misunderstand what OAuth actually does and how it works.

Is OAuth 2.0 Authentication or Authorization?

OAuth 2.0 is an authorization framework, not an authentication protocol. It controls what an app can do on your behalf — not who you are. This is the most common misconception about OAuth.

• Authorization answers: "What is this app allowed to access?"
• Authentication answers: "Who is this user?"

When you see "Login with Google," the identity part is handled by OpenID Connect (OIDC) — a thin layer on top of OAuth 2.0. OIDC adds a standardized ID Token with user identity, enabling single sign-on. OAuth itself only grants scoped access to resources. The OpenID Connect Core 1.0 spec defines this identity layer in detail.

What Are the Four Roles in OAuth 2.0?

OAuth 2.0 defines four distinct roles that separate concerns for secure delegated access. Consider this example: you want Instagram to import photos from your Google Photos library. Instagram needs access, but you don't want to give it your Google password.

• Resource Owner — You, the user. You own the photos and decide who gets access.
• Client — The app requesting access (Instagram). It wants your photos but has no built-in right to them.
• Authorization Server — The service that checks your identity and issues tokens after you consent (Google's OAuth server).
• Resource Server — The service hosting the protected data, which checks tokens on each API call (Google Photos API).

This role separation makes OAuth scalable and secure. The Authorization Server and Resource Server can be run by the same entity — in this case, both are Google.

What Are the OAuth 2.0 Grant Types?

OAuth 2.0 defines several grant types, each built for a different scenario. Picking the right one is critical for security. Here's how they compare:

The Authorization Code Grant is the most common and secure flow. The client gets a short-lived code, then swaps it for tokens through a secure server-to-server call. Tokens never touch the browser.

PKCE (Proof Key for Code Exchange, pronounced "pixy") extends this flow for public clients that can't store a secret — like SPAs and mobile apps. It adds a cryptographic challenge to block code interception attacks. Per RFC 9700 (OAuth 2.0 Security Best Current Practice), PKCE is now recommended for all OAuth clients, not just public ones.

The Client Credentials Grant covers machine-to-machine calls with no user involved — common in microservices and background jobs.

The Implicit Grant has been deprecated in the OAuth 2.1 draft spec because it returned tokens in the URL fragment, exposing them to interception. Modern SPAs should use Authorization Code with PKCE instead.

How Does the Authorization Code Flow Work?

The Authorization Code flow uses a six-step exchange to grant access without exposing credentials. Here's how it works using our Instagram and Google Photos example:

1. User initiates access. You click "Import from Google Photos" in Instagram. Instagram redirects your browser to Google's Authorization Server with the requested scopes (e.g., read-only photo access).
2. User authenticates and consents. Google shows a login screen (if needed) and a consent screen listing what Instagram is asking for. You review and approve.
3. Authorization code issued. Google generates a short-lived, single-use code and redirects your browser to Instagram's registered callback URL. This code alone can't access anything.
4. Code exchanged for tokens. Instagram's server sends the code, its client ID, and client secret directly to Google's token endpoint — a server-to-server request that never touches the browser. Google returns an access token and a refresh token.
5. Resource access. Instagram uses the access token to call the Google Photos API. The token goes in the HTTP Authorization header of each request.
6. Token refresh. When the access token expires, Instagram's server uses the refresh token to get a new one from Google — again server-to-server. Refresh tokens stay in the server's database and never reach the client.

How Do Access Tokens, Refresh Tokens, and Scopes Work?

OAuth replaces password sharing with tokens and scopes — following the principle of least privilege. Each piece has a specific job:

• Access Tokens are short-lived credentials, typically valid for 15 minutes to one hour. They grant scoped access to specific resources. If one gets compromised, the damage window is small.
• Refresh Tokens are long-lived and stored only on the server. When an access token expires, the server uses the refresh token to get a new one — no user interaction needed. Best practice is to rotate refresh tokens on each use, as outlined in RFC 6749 Section 6.
• Scopes set the boundaries. An app might request photos.readonly — read photos, but not delete or edit them. Users review scopes during the consent step.

What Are the Security Best Practices for OAuth 2.0?

A secure OAuth implementation requires strict token handling, PKCE enforcement, and URI validation. The OAuth 2.0 Security Best Current Practice (RFC 9700) outlines these key rules:

• Keep tokens server-side. Only the short-lived authorization code should pass through the browser. Access and refresh tokens belong on the server.
• Enforce token rotation. Short access token lifespans limit exposure. Rotating refresh tokens on each use prevents replay attacks.
• Use PKCE for all public clients. SPAs, mobile apps, and desktop apps must use PKCE (RFC 7636) to protect the code exchange.
• Validate redirect URIs strictly. Only allow pre-registered URIs. Open redirects can lead to code or token theft.
• Request minimal scopes. Ask only for what your app needs. Broad permissions widen the attack surface and hurt user trust.

Frequently Asked Questions

What is the difference between OAuth 2.0 and OpenID Connect?

OAuth 2.0 handles authorization — controlling what an app can access. OpenID Connect (OIDC) builds on top of OAuth to add authentication — verifying who the user is. OIDC introduces the ID Token, which carries user identity data for single sign-on flows.

Why was the Implicit Grant deprecated?

The Implicit Grant returned tokens directly in the URL fragment. This exposed them to browser history, referrer headers, and interception attacks. The OAuth 2.1 draft removes it entirely. SPAs should now use the Authorization Code flow with PKCE.

Should I use PKCE even for server-side applications?

Yes. While PKCE was originally designed for public clients, RFC 9700 recommends it for all OAuth clients as defense-in-depth. It protects against authorization code injection even when a client secret is present.

How long should OAuth access tokens last?

Most implementations set access tokens to expire between 15 minutes and one hour. Shorter lifespans reduce the damage window if a token is leaked. Refresh tokens handle seamless renewal without user interaction.

What is the difference between access tokens and refresh tokens?

Access tokens are short-lived (minutes to one hour) and sent with each API request. Refresh tokens are long-lived and stored on the server — used only to get new access tokens when the current one expires. Refresh tokens should be rotated on every use and can be revoked at any time.

Further Reading

• RFC 6749 — The OAuth 2.0 Authorization Framework
• RFC 7636 — Proof Key for Code Exchange (PKCE)
• OpenID Connect Core 1.0 Specification
• OAuth 2.0 Security Best Current Practice (RFC 9700)
• OAuth 2.1 Draft Specification

About JSS Tech

At JSS Tech, we help organizations build secure, scalable applications with modern authentication and authorization architectures. With over 15 years of experience in digital transformation, we specialize in production-ready cloud infrastructure, security engineering, and enterprise-grade automation solutions.