OAuth

OAuth (currently OAuth 2.0) is an open authorization protocol that lets a user grant one application limited, scoped access to their data on another application — without ever sharing their password with the requesting app. It's the protocol behind every "Sign in with Google," "Connect your Slack," or "Authorize this app to access your Gmail" flow. OAuth is fundamentally about authorization (what an app is allowed to do), which is a distinct concept from authentication (proving who a user is) — though OpenID Connect (OIDC) layers authentication on top of OAuth 2.0, which is why "Sign in with Google" flows use OIDC specifically. The standard OAuth 2.0 "Authorization Code" flow, most relevant to SaaS builders integrating third-party APIs, works like this: your app redirects the user to the provider's authorization URL with a requested `scope` (e.g., `read:calendar`); the user approves the request on the provider's own consent screen; the provider redirects back to your app with a one-time authorization `code`; your backend exchanges that code (plus your app's client secret) for an `access_token` and a `refresh_token`; your app then includes the access token in an `Authorization: Bearer {token}` header on every subsequent API call, and uses the refresh token to get a new access token once the old one expires (typically after 1 hour). Concrete worked example: a scheduling SaaS wants to read a user's Google Calendar to check availability. It redirects to `https://accounts.google.com/o/oauth2/v2/auth?client_id=...&scope=https://www.googleapis.com/auth/calendar.readonly&response_type=code&redirect_uri=https://yourapp.com/oauth/callback`. The user approves; Google redirects to `https://yourapp.com/oauth/callback?code=4/0AY0e-g7...`; your backend POSTs that code to Google's token endpoint and receives back `{"access_token": "ya29...", "refresh_token": "1//0g...", "expires_in": 3599}`. Your app stores the refresh token encrypted, and calls the Calendar API with the access token until it expires, then silently refreshes. Getting OAuth token storage, refresh logic, and scope minimization right is a common source of security bugs in SaaS integrations — leaked refresh tokens are equivalent to a permanent backdoor into a user's connected account, which is why mature implementations encrypt tokens at rest, scope every request to the minimum permissions actually needed (never request broad "full account access" when read-only calendar access will do), and support token revocation so a user disconnecting an integration actually invalidates the stored credentials rather than just hiding a UI toggle. Newer specifications worth knowing — PKCE (Proof Key for Code Exchange), now recommended for all OAuth flows including server-side ones, and device authorization grant (used for TVs, CLIs, and other input-constrained devices) — extend the core OAuth 2.0 flow to close specific security gaps or support clients that can't handle a standard browser redirect, and any SaaS product building a public developer platform should implement PKCE by default rather than treating it as mobile-only.