OAuth 2.0

What is OAuth 2.0?

OAuth 2.0 is a standard protocol for delegated authorization. It lets a user grant a third-party app limited access to their data at another service — for example, allowing a calendar app to read Google Calendar events without giving it their Google password.

Key roles

• Resource owner — the user
• Client — the app requesting access
• Authorization server — issues tokens after login/consent
• Resource server — API holding protected data

Common flows

Flow	Typical use
Authorization Code	Web and mobile apps with a backend
Client Credentials	Machine-to-machine (no user)
Device Code	TVs and CLI devices with limited input

OAuth vs authentication

OAuth is about authorization (what you can access). OpenID Connect (OIDC) builds on OAuth to add authentication (who you are) via ID tokens.

Tokens

• Access token — short-lived key presented to APIs
• Refresh token — long-lived, used to obtain new access tokens
• Scopes — limit what the token can do (read:email, write:files)

In cloud/SaaS products

B2B SaaS often supports “Sign in with Google/Microsoft” (OIDC) and offers OAuth apps so customers integrate via API with scoped tokens.

What people get wrong

• Using OAuth as login without OIDC. An access token proves authorization, not identity; “who is this user” needs OpenID Connect’s ID token, or you’re vulnerable to token-substitution mistakes.
• Skipping PKCE. Mobile and single-page apps must use Authorization Code + PKCE; the old implicit flow is deprecated for good reasons.
• Over-asking scopes. Requesting full_access when you need read:calendar fails security reviews and scares users off the consent screen.
• Storing tokens carelessly. Access tokens in localStorage are one XSS away from theft; prefer httpOnly cookies or backend-held tokens.

The Authorization Code Flow

The most common and secure OAuth 2.0 flow for web applications, the authorization code flow, works in stages specifically designed to avoid ever exposing a long-lived access token to the browser directly: the user is redirected to the authorization server to log in and approve access, the authorization server redirects back with a short-lived authorization code, and the application’s backend server exchanges that code for an access token in a direct, server-to-server request — a step the browser never sees. This backend-only token exchange is what distinguishes secure OAuth implementations from less secure legacy flows (like the deprecated implicit grant), and understanding this flow is foundational to implementing “Sign in with Google” or similar third-party login buttons correctly and securely.