Without OAuth: You give the app your Google password → full access to everything

With OAuth: Google asks "Allow this app to see your photos?" → You say yes → App gets a limited token → You can revoke it anytime

Step 1: User clicks "Sign in with Google"
        → Client redirects browser to Google's /authorize endpoint

Step 2: Client sends authorization request:
        GET https://accounts.google.com/o/oauth2/auth?
            client_id=abc123&
            redirect_uri=https://myapp.com/callback&
            response_type=code&
            scope=openid profile email&
            state=RANDOM_CSRF_TOKEN

Step 3: Google shows consent screen:
        "MyApp wants to access your email and profile"

Step 4: User clicks "Allow"

Step 5: Google redirects back with authorization code:
        https://myapp.com/callback?code=AUTH_CODE_xyz789&state=RANDOM_CSRF_TOKEN

Step 6: Client exchanges code for token (server-to-server):
        POST https://oauth2.googleapis.com/token
        Body: code=AUTH_CODE_xyz789&
              client_id=abc123&
              client_secret=SECRET_456&
              redirect_uri=https://myapp.com/callback&
              grant_type=authorization_code

Step 7: Google returns access token (and optionally refresh token):
        {
          "access_token": "eyJhbGciOiJSUzI1NiIs...",
          "token_type": "Bearer",
          "expires_in": 3600,
          "refresh_token": "1//0gABCdefGHI...",
          "scope": "openid profile email"
        }

Step 8: Client uses access token to call API:
        GET https://www.googleapis.com/oauth2/v3/userinfo
        Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

Step 9: Resource Server validates token and returns data:
        {
          "sub": "1234567890",
          "name": "Alice Smith",
          "email": "alice@example.com"
        }

Standard Authorization Code flow:
  Client → Auth Server: "Give me a code"
  Auth Server → Client: "Here's code xyz"
  Client → Auth Server: "Exchange xyz for token"

With PKCE:
  Client generates: code_verifier = "dBjftJeZ4CVP-mB92K27uhbUJU1p1r"
  Client computes:  code_challenge = SHA256(code_verifier)

  Client → Auth Server: "Give me a code (challenge: SHA256 result)"
  Auth Server → Client: "Here's code xyz (stores challenge)"
  Client → Auth Server: "Exchange xyz for token (here's the original verifier)"
  Auth Server verifies: SHA256(verifier) === stored_challenge ✓

✅ OAuth 2.0 Security Checklist:

• ✓ Always use HTTPS for all OAuth endpoints
• ✓ Use Authorization Code + PKCE (not Implicit or ROPC)
• ✓ Validate the state parameter to prevent CSRF
• ✓ Use exact redirect URI matching (no wildcards)
• ✓ Never expose client_secret in browser-side code
• ✓ Set short token expiration (15-60 min for access tokens)
• ✓ Implement refresh token rotation
• ✓ Store tokens in httpOnly cookies or secure backend storage
• ✓ Validate tokens on every API request
• ✓ Implement token revocation for logout
• ✓ Use the Security Headers Analyzer on your OAuth endpoints
• ✓ Set appropriate CORS headers with the CORS Header Generator

CSRF Attack: An attacker initiates an OAuth flow with their own account, gets your app to link to the attacker's account. Without state validation, you can't detect this.

Fix: Generate a random state, store it in the session, and verify it when the callback arrives.

Token Exposure: The Implicit grant puts the access token directly in the URL fragment, making it visible in browser history, referrer headers, and logs.

Fix: Use Authorization Code + PKCE instead. The token is exchanged server-to-server.

Open Redirect: If you allow https://myapp.com/* as a redirect URI, an attacker can redirect the authorization code to https://myapp.com/evil.

Fix: Use exact redirect URI matching. Register https://myapp.com/callback, not https://myapp.com/*.

User tells Authorization Server: "I trust this app — give it a limited token."

The app never sees the password. The token is scoped, temporary, and revocable.

Related BestWordz Resources

• JWT Explained: Header, Payload and Signature — How access tokens work
• Hashing vs Encryption vs Encoding — The crypto behind OAuth tokens
• How HTTPS and TLS Actually Work — TLS protects OAuth in transit
• Protecting API Keys and Secrets — Why client_secret must stay server-side
• Hashing vs Encryption vs Encoding Demo — Interactive comparison

Explore all BestWordz Cybersecurity Tools →

Further Reading

• RFC 6749 — The OAuth 2.0 Authorization Framework
• RFC 7636 — PKCE (Proof Key for Code Exchange)
• OAuth 2.1 Draft — Consolidated best practices
• OAuth.net — Official OAuth 2.0 resource
• OWASP OAuth 2.0 Cheat Sheet