OAuth: The Secret Behind "Sign in with Google"

Ever clicked that handy "Sign in with Google" button instead of creating yet another username and password? You're not alone! Behind that convenient button lies a powerful technology called OAuth that's keeping your digital life secure.

In this article, we’ll explore:

• What OAuth is
• How it works (with a real-world example)
• Key concepts in OAuth
• A step-by-step OAuth flow
• When and why to use OAuth

No more waiting, Let’s get started!

What is OAuth?

OAuth (short for Open Authorization) is a protocol that allows an app to gain limited access to a user’s data on another service — without needing the user’s password.

Imagine you want to print photos from your Instagram account using a third-party photo printing app. How can this third-party app access your photos?

If your photos are public, there’s no issue — you simply provide your Instagram username, and the app can retrieve them using the Instagram API.

But the problem arises when you want to print private photos. One option is to give your username and password to the third-party app. Sounds quick and easy, right? The app might promise to only access your photos and not alter or view anything else. But can you really trust a third-party app with your full credentials?

Instead of sharing your Instagram username and password, OAuth lets you authorize the app to access only your photos — and nothing else. Your credentials remain safe, and you stay in control of what the app can access.

Why Use OAuth?

• Security: Your password is never shared with the third-party app.
• Control: You can decide what the app can and cannot do (e.g., read photos but not delete them).
• Revocability: You can cancel access anytime from your account settings.

Key Concepts in OAuth

Before jumping into the process, let’s understand some basic terms:

• Resource Owner
  The user who owns the data (you).

• Client
  The third-party app that wants to access your data (e.g., a photo printing service).

• Authorization Server
  The server that asks the user for permission and issues tokens (e.g., accounts.google.com).

• Resource Server
  The server that holds the user’s data (e.g., Google Photos API).

• Access Token
  A temporary key that the client uses to access your data on the resource server.

How OAuth Works: Step-by-Step (Authorization Code Flow)

Let’s break it down using a common flow — Authorization Code Flow, used by web apps.

Real-world example: Let’s say PhotoPrintApp wants to access your Google Photos.

Step 1: The Client (PhotoPrintApp) redirects you to Google

https://accounts.google.com/o/oauth2/v2/auth?
client_id=PHOTO_PRINT_APP_ID&
redirect_uri=https://photoprintapp.com/callback&
response_type=code&
scope=photos.readonly

You are shown a Google login screen asking if you allow the app to access your photos.

Step 2: You approve and Google redirects back with an authorization code

https://photoprintapp.com/callback?code=AUTH_CODE

Step 3: The app exchanges the code for an access token

https://oauth2.googleapis.com/token

Content-Type: application/x-www-form-urlencoded

client_id=PHOTO_PRINT_APP_ID&
client_secret=APP_SECRET&
code=AUTH_CODE&
grant_type=authorization_code&
redirect_uri=https://photoprintapp.com/callback

Step 4: Google responds with an access token

{
  "access_token": "ya29.a0ARrdaM...",
  "expires_in": 3600,
  "token_type": "Bearer",
  "refresh_token": "1//06vXYZ..."
}

Step 5: The app uses the access token to access your photos

https://photoslibrary.googleapis.com/v1/mediaItems

Authorization: Bearer ya29.a0ARrdaM...

That’s it! You didn’t share your password, and you can revoke access anytime.

What is Refresh Token?

Access tokens expire (usually within an hour). A refresh token allows the app to get a new access token without bothering you again.

This helps apps maintain access without asking you to log in every hour.

Scopes in OAuth

Scopes define what the app can do. Here are some examples:

Apps request scopes during the authorization step, and you choose what to allow.

Here’s a simple fetch request to use the access token:

fetch("https://www.googleapis.com/oauth2/v3/userinfo", {
  headers: {
    "Authorization": "Bearer ya29.a0ARrdaM..."
  }
})
  .then(res => res.json())
  .then(data => console.log(data));

OAuth 2.0 grant types

Authorization Code Grant (with optional PKCE)

Recommended for: Web applications (server-side), Single Page Applications (SPA) with PKCE Most secure — does not expose tokens in the browser

How it works:

User is redirected to the authorization server.

After login and consent, an authorization code is returned to the client.

The client exchanges the code (server-to-server) for an access token (and optionally a refresh token).

PKCE (Proof Key for Code Exchange) enhances security for public clients like SPAs and mobile apps.

Implicit Grant (Deprecated)

Not recommended anymore — replaced by Authorization Code with PKCE

Used to be used by client-side applications (like SPAs) where the access token is returned directly in the redirect URL. But it's insecure because the token is exposed in the browser and can't be refreshed securely.

Client Credentials Grant

Recommended for: Machine-to-machine (M2M) or server-to-server communication (no user)

How it works:

The client authenticates itself (client ID + secret).

It receives an access token on its own behalf (no user involved).

Example: A backend service querying an API for internal data processing.

Resource Owner Password Credentials Grant (Not recommended)

Deprecated in many cases due to security concerns

The user provides their username and password directly to the app, which then exchanges them for an access token.

Useful only in high-trust environments (e.g., first-party apps), but not recommended for public clients or third-party apps.

Refresh Token Grant

Used to get a new access token when the old one expires — without asking the user to log in again.

Only available if the initial flow (like Authorization Code) returned a refresh token.

Useful for long-lived sessions (e.g., mobile apps).

OAuth Is Not for Authentication

Many developers confuse OAuth with authentication (logging in). But OAuth is for authorization — it allows an app to access specific data on behalf of the user.

So if you just want to allow an app to view your Instagram photos, OAuth is perfect.

But what if an app needs to know who you are — not just access your data?

That’s where OpenID Connect (OIDC) comes in.

What Is OpenID Connect?

OpenID Connect is a simple identity layer built on top of OAuth 2.0. While OAuth handles access to resources, OpenID Connect handles identity — confirming who the user is.

Let’s say you visit a new app and see a “Login with Google” button. When you click it, the app uses OpenID Connect to verify your identity through Google. You never enter a password on the app itself — you’re redirected to Google, and once you authenticate, the app receives an ID token that proves who you are.

This way:

• You don't need to create a new username/password.
• The app knows who you are (authentication),

And, using OAuth, it can optionally get access to certain data (authorization), like your email or profile picture.

Security Best Practices

• Never store access tokens in localStorage (use HTTP-only cookies for sensitive apps).
• Always use HTTPS.
• Limit scopes.
• Use short-lived tokens.