Understanding OAuth: What Happens When You "Login with Google"

Yami -

Imagine you want an app to do one small thing with your account — for example, let a photo app add pictures to your cloud storage. You don't want to share your password. Instead, you give the app a temporary key that only works for that one task. That's exactly what happens when you click "Login with Google" — you're using OAuth, a system that gives apps a limited, temporary key instead of your password.

This post focuses on OAuth 2.0, the modern standard used by most platforms today (OAuth 1.0 is noted where relevant as historical context).

1. Why Was OAuth Created?

Before OAuth, apps that needed access to your data often asked for your username and password. That meant:

  • You had to give the app full access to your account.
  • If the app were compromised, your account could be at risk.

For example, to let a photo app add pictures to your cloud storage, you would have to share your password. That gave the app access to everything, not just photos.

OAuth solved this by letting you grant a limited, temporary key (a token) that only allows the specific action the app needs.

2. The Birth and Evolution of OAuth

OAuth started in November 2006 as a practical solution to the problem of sharing credentials with third-party apps. Early contributors included developers from Twitter and Google who wanted a way to delegate limited access without handing out passwords.

Key milestones:

  • 2007 — OAuth Core 1.0: introduced signed requests and request tokens to protect delegated access.
  • 2010 — OAuth 1.0a: fixed a security flaw in the original specification.
  • 2012 — OAuth 2.0 (RFC 6749): redesigned the model around token-based flows to better support web, mobile, and modern APIs.
  • 2023-present — OAuth 2.1: consolidating best practices and removing deprecated flows.

Why this matters today: OAuth 1.0 introduced important security ideas but was complex to implement. OAuth 2.0 keeps those security goals while being much more flexible and easier to adopt. The rest of this article focuses on OAuth 2.0, the modern standard used by most major providers.

3. What Is OAuth?

At its core, OAuth is about authorization — giving applications permission to access data on your behalf.
It allows users to delegate access to their data securely, using tokens instead of passwords.
A token acts like a "temporary key" that allows access only to specific resources for a limited time.

Important OAuth Terminology:

  • Authorization Server — The service that authenticates the user and issues tokens (e.g., Google's OAuth server)
  • Resource Server — The API that holds the user's data (e.g., Google Drive API)
  • Client — Your application requesting access to user data
  • Resource Owner — The user who owns the data
  • Access Token — A credential used to access protected resources
  • Refresh Token — A credential used to obtain new access tokens when they expire

Example:
You allow a fitness app to sync your Google Calendar to schedule workouts.
The app never sees your Google password — it only gets permission to view or update your events.

4. Why OAuth Matters

Here’s why OAuth became the foundation of modern web security:

  • Security — no password sharing between systems.
  • Fine-grained permissions — apps get access only to what’s needed.
  • Revocable access — users can revoke tokens anytime.
  • Standardized architecture — works across languages and frameworks.
  • Extensible — forms the base for OpenID Connect (OIDC), which adds authentication on top.

5. How Does OAuth Work?

Let's explain OAuth using the temporary-key example from the intro.

The Players:

  • You (the user who owns the data)
  • The App (the app that wants access)
  • The Authorization Service (Google/Facebook that issues keys)
  • Your Data (the resources that need to be accessed)

Here's what happens when you click "Login with Google":

  1. You tell the app you want to use your Google account.
  2. Google shows a screen asking, "Is it okay to share your info with this app?"
  3. If you say yes, Google gives the app a short-lived key that only allows the agreed action.
  4. The app uses this key to access only the data and actions you allowed.
  5. When the key expires, the app can no longer access your data unless you grant a new key.

The best part? If something goes wrong, you can revoke that key without changing your main password.

6. OAuth 2.0 Flows — Details and Diagrams

Below are short explanations and simple sequence diagrams for the most common OAuth 2.0 grant types.

Description: The app redirects the user to the authorization server to log in and consent. The server returns an authorization code to the app, which the app exchanges for an access token (and optionally a refresh token).

What is PKCE? Proof Key for Code Exchange (pronounced "pixie") is a security extension that prevents authorization code interception attacks. It's essential for mobile apps and single-page applications where the client secret cannot be securely stored.

Client Credentials (machine-to-machine)

Description: The client (typically a backend service) authenticates directly with the authorization server and requests an access token to call resource APIs.

Device Code (devices with limited input)

Description: Devices without a browser prompt the user to visit a URL on another device and enter a code. The device polls the authorization server until the user completes consent.

Refresh Token (renewing access)

Description: When an access token expires, the client can use a refresh token to request a new access token without asking the user to authenticate again.

7. OAuth Scopes and Permissions

Scopes define what an app can do with your data. They're like permission levels that you grant during the OAuth flow.

Important: Scope syntax and names vary by OAuth provider. Some use URLs (Google), others use simple strings (GitHub, Facebook).

Common OAuth Scopes:

  • read / write — Basic read/write access
  • profile — Access to user profile information
  • email — Access to email address
  • openid — Required for OpenID Connect
  • offline_access — Allows refresh tokens for long-term access

Provider-Specific Examples:

Google:

  • https://www.googleapis.com/auth/calendar.readonly — Read calendar events
  • https://www.googleapis.com/auth/userinfo.email — Access the user's email

GitHub:

  • repo — Full control of private repositories
  • user:email — Access user email addresses
  • read:org — Read organization membership

Microsoft (Azure AD):

  • User.Read — Read user profile
  • Files.ReadWrite — Read and write user files

Best Practices:

  • Request minimal scopes needed for your app's functionality
  • Clearly explain what each scope allows in your consent screen
  • Allow users to modify granted scopes later
  • Validate scopes on both client and server side

8. Real-World Use Cases

OAuth is everywhere — powering both consumer and enterprise systems:

  • Social logins: Google, Facebook, GitHub, LinkedIn
  • API integrations: Connecting Slack, Salesforce, or Google Analytics
  • Enterprise identity: OAuth with Azure AD or OneLogin
  • IoT devices: TVs, smart speakers, and wearables authenticating without keyboards

9. OAuth vs OpenID Connect: What's the Difference?

Short answer:

  • OAuth controls what an app can do — it issues short-lived keys (access tokens) the app uses to access resources. Example: "This app can read your calendar."

  • OpenID Connect (OIDC) proves who you are — it issues an ID token that tells the app the user's identity. Example: "This token says you are jane@example.com."

Most real-world logins use both OIDC to authenticate the user (who are you?) and OAuth to authorize access (what can the app do?).

10. Token Types: JWT vs Opaque Tokens

OAuth access tokens come in two main types:

JWT (JSON Web Token):

  • Self-contained tokens that include user information and claims
  • Can be validated without calling the authorization server
  • Larger in size (typically 500-2000 bytes)
  • Cannot be revoked easily (valid until expiration)
  • Use when: You need offline validation, stateless architecture

Opaque Tokens:

  • Random strings that reference data stored on the authorization server
  • Require validation via the token introspection endpoint
  • Smaller in size (typically 20-50 bytes)
  • Can be easily revoked server-side
  • Use when: You need instant revocation, sensitive data protection

Best Practice: Use short-lived JWT access tokens (5-15 minutes) with opaque refresh tokens for optimal security.

11. Best Practices for Secure Implementation

  • Always use PKCE (Proof Key for Code Exchange) for public clients.
  • Enforce HTTPS everywhere.
  • Never expose client secrets in frontend code.
  • Use short-lived tokens and refresh tokens responsibly.
  • Validate token scopes and signatures before use.

12. Common OAuth Implementation Pitfalls & Solutions

CORS Issues:

  • Problem: Browser blocks OAuth redirects due to CORS policy
  • Solution: Configure your OAuth provider to allow your domain in redirect URIs

Token Storage:

  • Problem: Storing tokens insecurely (localStorage in browsers)
  • Solution: Use httpOnly cookies for access tokens, encrypted database storage for refresh tokens

PKCE Implementation:

  • Problem: Incorrect code challenge/verifier generation
  • Solution: Use crypto libraries for proper SHA256 hashing and base64url encoding

State Parameter Missing:

  • Problem: Vulnerable to CSRF (Cross-Site Request Forgery) attacks
  • Solution: Always include random state parameter and validate it. The state parameter is a random value sent with the authorization request and verified when the user returns to prevent attacks

Redirect URI Mismatch:

  • Problem: Authorization fails due to redirect URI not matching registered value
  • Solution: Ensure exact match (including trailing slashes, http vs https, ports). Register all necessary redirect URIs with your OAuth provider

Token Expiration Handling:

  • Problem: App crashes when tokens expire
  • Solution: Implement refresh token logic with proper error handling

Scope Creep:

  • Problem: Requesting too many permissions
  • Solution: Follow principle of least privilege, request only needed scopes

Debugging Tips:

  • Use OAuth playground tools (Google OAuth Playground, OAuth Debugger)
  • Enable detailed logging in your OAuth library
  • Test with different browsers and devices
  • Monitor token expiration times

13. The Future of OAuth

The next generation, OAuth 2.1, is currently being standardized. It consolidates best practices by:

  • Removing legacy flows (Implicit Grant, Resource Owner Password Credentials (ROPC) Grant)
  • Requiring PKCE for all public clients
  • Simplifying authorization server configuration

As APIs become more distributed and privacy regulations tighten, OAuth will continue evolving as a cornerstone of secure digital identity.

Conclusion

OAuth is more than just a login mechanism — it's the foundation of secure authorization in a connected world. By understanding OAuth's flows, scopes, and best practices, you can build applications that respect user privacy while enabling powerful integrations.

Resources to Explore: