OAuth 2 is the industry-standard authorization framework that lets third-party apps securely access user data without ever handling passwords. Instead of asking users to share credentials, OAuth 2 delegates authentication to the service provider (like Google, GitHub, or Progressive Robot) and issues limited, revocable tokens that represent specific permissions.

OAuth 2 answers “What can this app do?” — not “Who is this user?” (that’s authentication). When you see “Sign in with Google,” that’s usually OpenID Connect (which adds identity) built on top of OAuth 2.

This complete 2025–2026 guide explains how OAuth 2 works, the different grant types and when to use each, security must-haves (PKCE, state validation, token handling), common pitfalls, and production-ready implementation patterns — so you can build secure, reliable integrations every time.

Key Takeaways

  • OAuth 2 is authorization, not authentication — use OpenID Connect when you need identity + permissions.
  • Four core roles: Resource Owner (user), Client (your app), Authorization Server (token issuer), Resource Server (API).
  • Authorization Code + PKCE is the gold standard for web/mobile apps — never use deprecated flows (Implicit, Password).
  • Scopes define granular permissions — always request the minimum needed to improve user trust and authorization rates.
  • Tokens expire — use refresh tokens for seamless renewal; never expose them client-side.
  • State parameter + PKCE prevent CSRF and code interception attacks — mandatory for security.
  • Client secrets must stay server-side — public clients (SPAs, mobile) use PKCE instead.
  • It replaces insecure alternatives (sharing passwords/API keys) and is used by billions of daily authorizations.

What Is OAuth 2?

OAuth 2 (defined in RFC 6749) is an authorization framework that enables third-party applications to obtain limited access to a user’s resources on an HTTP service without exposing user credentials.

Think of it as a valet key for your car: you give limited access (start engine, open doors) without handing over the full keyring (trunk, garage door). Similarly, OAuth 2 grants specific permissions (scopes) to access resources (files, profile, emails) without giving full account control.

It solves a core security problem: applications no longer need to store user passwords or require users to share API keys. Users authorize via the service provider, which issues tokens representing the granted permissions — revocable anytime.

How OAuth 2 Works: The Core Flow

It follows a six-step pattern across all grant types:

  1. Client requests authorization — redirects user to authorization server with requested scopes.
  2. User approves — logs in (if needed) and consents to permissions.
  3. Client requests access token — exchanges authorization grant for token (server-to-server).
  4. Authorization server issues token — returns access token (± refresh token).
  5. Client accesses protected resource — uses token to make API calls.
  6. Resource server validates token — serves data if token is valid and has required scopes.

The grant type determines steps 1–4; steps 5–6 are identical.

OAuth 2 vs Authentication vs OpenID Connect

 
 
AspectOAuth 2AuthenticationOpenID Connect
PurposeAuthorization (permissions)Identity verificationBoth identity + permissions
Answers“What can this app do?”“Who is this user?”“Who is this user and what can they do?”
Token TypeAccess tokenSession token/cookieID token + access token
Use CaseAPI access, third-party integrationsYour own login systemSocial login, SSO
ExampleBackup app accessing Google DriveLogging into your email“Sign in with Google” button
 

OAuth 2 alone = authorization only. OpenID Connect = OAuth 2 + identity (ID token with user info). Use OAuth 2 for API access; use OpenID Connect for social login.

OAuth 2 Roles

  1. Resource Owner — the user who owns the data and grants access.
  2. Client — your application requesting access (web, mobile, server).
  3. Authorization Server — authenticates user and issues tokens (e.g., Google’s auth server).
  4. Resource Server — hosts protected resources and validates tokens (often same as authorization server).

From your perspective, the service (e.g., Progressive Robot API) usually combines authorization + resource server roles.

Application Registration & Client Credentials

Before using it, register your app in the provider’s developer portal.

Required info:

  • App name (shown to users)
  • Website URL
  • Redirect URI(s) — exact callback URLs (must match exactly)

Issued credentials:

  • Client ID — public identifier (safe in frontend code)
  • Client Secret — confidential key (keep server-side only!)

Never expose client secrets in:

  • JavaScript/mobile apps (use PKCE)
  • Git repos
  • URLs/query params
  • Logs/error messages

OAuth 2 Grant Types – Which to Use

 
 
Grant TypeBest ForClient TypeSecurity LevelUser Interaction Required?
Authorization Code + PKCEWeb apps, mobile apps, SPAsPublic/ConfidentialHighestYes
Client CredentialsMachine-to-machine, server-to-serverConfidentialHighNo
Device CodeSmart TVs, IoT, CLI toolsPublicHighYes (on second device)
 

Deprecated / Never Use:

  • Implicit Flow — tokens in URL fragment (vulnerable to interception)
  • Resource Owner Password Credentials — sends user password to your app (huge risk)

Authorization Code Flow + PKCE (Recommended)

When to use: Almost all cases — web, mobile, SPA, desktop apps.

Why PKCE: Protects against code interception attacks (essential for public clients).

Flow Steps:

  1. Generate code_verifier (random string) & code_challenge (SHA256 hash)
  2. Redirect user to authorization URL with code_challenge & code_challenge_method=S256
  3. User approves → authorization code sent to redirect URI
  4. Server exchanges code + code_verifier for tokens
  5. Server validates challenge matches → issues access token

Security win: Even if code is intercepted, attacker can’t exchange without verifier.

Client Credentials Flow (Machine-to-Machine)

When to use: No user involved — app accessing its own resources.

Flow:

				
					POST /token
grant_type=client_credentials
client_id=CLIENT_ID
client_secret=CLIENT_SECRET
scope=read

Response:

				
					{
  "access_token": "TOKEN",
  "expires_in": 3600,
  "token_type": "bearer"
}

No refresh token — re-request when expired.

Using Access Tokens

Send in Authorization header:

				
					curl -H "Authorization: Bearer ACCESS_TOKEN" https://api.progressiverobot.com/v2/droplets

Common responses:

  • 200 OK — success
  • 401 Unauthorized — invalid/expired token
  • 403 Forbidden — valid token but insufficient scope

Refresh Token Flow

When access token expires:

				
					POST /token
grant_type=refresh_token
refresh_token=REFRESH_TOKEN
client_id=CLIENT_ID
client_secret=CLIENT_SECRET

Best practice: Store refresh tokens encrypted; revoke on logout.

Common OAuth 2 Implementation Mistakes

  1. Exposing client secrets client-side → Use PKCE for public clients.
  2. Missing state validation → Enables CSRF attacks.
  3. Wildcard/insecure redirect URIs → Allows code theft.
  4. Storing tokens in localStorage → Vulnerable to XSS.
  5. Not refreshing tokens → Sudden 401 errors.
  6. Requesting too many scopes → Lowers user approval rates.
  7. Ignoring token expiration → Breaks user experience.

Conclusion

OAuth 2 is the foundation of secure delegated access in modern applications. Use Authorization Code + PKCE for user-facing apps, Client Credentials for server-to-server, and always follow security best practices: exact redirect URI validation, state parameter, secure token storage, minimal scopes, and proper error handling.

Mastering OAuth 2 lets you build integrations that users trust — without ever touching passwords.

Recommended Resources

  • RFC 6749 – OAuth 2.0 Authorization Framework
  • RFC 8252 – OAuth 2.0 for Native Apps (PKCE)
  • OAuth 2.1 Draft (modern best practices)
  • OWASP OAuth Cheat Sheet
  • Progressive Robot API OAuth Documentation
Contact Us