OAuth 2.0
Security Patterns

Meaning

OAuth 2.0 is an authorization framework that enables a client application to obtain limited access to a protected resource on behalf of a user without exposing the user's credentials. It solves the pain point of delegating authority securely across domains. It is typically reached for web, mobile, or API integrations that need third‑party access to user data.

Primary Function

Authorization

Communicative Purpose

Enables delegated access to protected resources without sharing user credentials.

Pattern

client requests authorization → authorization server issues token → client presents token to resource server

Função primária

Authorization

Propósito comunicativo

Enables delegated access to protected resources without sharing user credentials.

Situações de gatilho

Web application: third‑party app needs to read a user's calendar events Mobile app: wants to post to a user's social media feed API service: server‑to‑server integration requires limited access to another service's data

Contextos

Web APIs, mobile back‑ends, microservice architectures, cloud platforms, SaaS integrations.

Padrão

client requests authorization → authorization server issues token → client presents token to resource server

Colocados típicos

  • access token
  • refresh token
  • authorization code
  • scope
  • redirect_uri
  • client_id
  • client_secret

Substituições comuns

  • Use OpenID Connect on top of OAuth 2.0 for identity verification Swap the authorization code grant for the client credentials grant in server‑to‑server scenarios Replace bearer tokens with MAC tokens for added request integrity

Erros comuns

Storing access tokens in client‑side local storage → vulnerable to XSS theft Using the implicit grant for confidential clients → token leakage through browser history Not validating the redirect_uri parameter → open‑redirect attacks Transmitting tokens over HTTP instead of HTTPS → token interception Confusing scopes with actual permissions → over‑privileged tokens

Similar / contraste

OAuth 1.0a – uses cryptographic signatures instead of bearer tokens API keys – static secrets without expiration or revocation SAML – XML‑based federation protocol for enterprise SSO

Interferências

Coming from Basic Auth: assuming a username/password can be sent directly in the Authorization header → OAuth 2.0 requires a token exchange flow Coming from SOAP: expecting WS‑Security headers for authentication → OAuth 2.0 uses bearer tokens in the HTTP Authorization header

Família do chunk

  • OAuth 2.0
  • OpenID Connect
  • JWT
  • PKCE
  • OAuth 1.0a

Nuance

Do not use OAuth 2.0 for simple internal services where a shared secret suffices; it adds unnecessary complexity Token introspection adds latency on each request; cache validated tokens when possible Refresh token revocation may not be immediate; plan for short token lifetimes if real‑time revocation is required

Efeito pragmático

Allows third‑party applications to act on a user's behalf securely, enabling rich ecosystems while keeping user credentials private.

Dica de memória

Think of OAuth 2.0 as a valet key: it lets a guest drive the car (access resources) but never opens the trunk (user password).

Nota

OAuth 2.0 is a framework; specific grant types (authorization code, client credentials, etc.) define concrete flows.

Upgrade path

After mastering OAuth 2.0, move to OpenID Connect for standardized identity layers.

Frequência: MediumFormulaicidade: FixedTipo de construção: conceptPrioridade de aquisição: Active recallPrioridade de output: BothTag de espaçamento: Medium-term

Log in to save chunks.