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.