Skip to content
cybersecurity authentication

OAuth (OAuth)

oauth authentication authorization sso
Plain English

OAuth is the system behind every “Sign in with Google” or “Login with GitHub” button. Instead of creating a new username and password for every website, you let the site ask Google (or GitHub, or Apple) to verify who you are. You never give the third-party site your Google password. Google confirms your identity and the site gets a temporary access token with limited permissions. You stay in control of what each app can access.

Technical Definition

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

Key roles:

  • Resource Owner: the user who owns the data
  • Client: the third-party application requesting access
  • Authorization Server: issues access tokens after authenticating the user (e.g., Google, GitHub)
  • Resource Server: hosts the protected resources (API)

Authorization Code flow (most common, server-side apps):

  1. Client redirects user to authorization server with client_id, redirect_uri, scope, state
  2. User authenticates and consents to the requested scopes
  3. Authorization server redirects back to client with an authorization code
  4. Client exchanges the code for an access token (server-to-server, using client_secret)
  5. Client uses the access token to call the resource API

Token types:

  • Access token: short-lived (minutes to hours), used to access APIs
  • Refresh token: long-lived, used to obtain new access tokens without re-authentication
  • ID token (OpenID Connect): JWT containing user identity claims (name, email, picture)

OAuth 2.0 scopes limit what the token can access: read:user, repo, email, openid profile.

PKCE (Proof Key for Code Exchange): extension for public clients (mobile apps, SPAs) that prevents authorization code interception. Now recommended for all OAuth flows.

OAuth 2.0 Authorization Code flow

# Step 1: Redirect user to authorization endpoint
https://github.com/login/oauth/authorize?\
  client_id=abc123&\
  redirect_uri=https://myapp.com/callback&\
  scope=read:user%20repo&\
  state=random_csrf_token

# Step 2: User authenticates, GitHub redirects back with code
# https://myapp.com/callback?code=AUTH_CODE&state=random_csrf_token

# Step 3: Exchange code for access token (server-side)
$ curl -X POST https://github.com/login/oauth/access_token \
  -H "Accept: application/json" \
  -d "client_id=abc123" \
  -d "client_secret=secret456" \
  -d "code=AUTH_CODE" \
  -d "redirect_uri=https://myapp.com/callback"
{"access_token": "gho_xxxxxxxxxxxx", "token_type": "bearer", "scope": "read:user,repo"}

# Step 4: Use access token to call API
$ curl -H "Authorization: Bearer gho_xxxxxxxxxxxx" \
  https://api.github.com/user
{"login": "mokeybytes", "name": "Mokey Bytes", ...}
In the Wild

OAuth powers authentication for the modern web. “Sign in with Google/GitHub/Apple” is OAuth. Every API integration that requires user authorization (Slack bots, GitHub Apps, Google Drive integrations) uses OAuth. In enterprise environments, OAuth combined with OpenID Connect (OIDC) enables Single Sign-On (SSO) across all internal and SaaS applications. The most common OAuth security mistakes are: not validating the state parameter (CSRF vulnerability), storing tokens in localStorage (XSS risk), using the implicit flow (deprecated, tokens exposed in URL), and requesting overly broad scopes. MCP servers that connect to external services (Google Workspace, Slack, GitHub) use OAuth to authenticate users without handling their passwords.