OAuth 2.0

OAuth 2.0 es el protocolo estándar para la autorización delegada — permite que una aplicación de terceros acceda a recursos que controlas en otro servicio sin entregar tu contraseña. “Iniciar sesión con Google,” “Conecta tu cuenta de GitHub,” “Otorga a Zapier acceso a tu Gmail” todos usan OAuth.

Los cuatro roles: propietario del recurso (el usuario), cliente (la aplicación de terceros), servidor de autorización (el servicio que emite OAuth, por ejemplo, accounts.google.com), servidor de recursos (la API que el cliente quiere llamar, por ejemplo, gmail.googleapis.com).

El flujo más común (código de autorización con PKCE):

1. El cliente redirige al usuario al servidor de autorización.
2. El usuario inicia sesión y aprueba los ámbitos solicitados.
3. El servidor de autorización redirige de vuelta con un código de autorización de un solo uso.
4. El cliente intercambia el código (más el verificador PKCE) por un token de acceso.
5. El cliente llama al servidor de recursos con el token de acceso.

OAuth 2.0 es solo de autorización. OpenID Connect (OIDC) es la capa de autenticación encima — añade un token de ID (un JWT con reclamaciones sobre quién es el usuario) para que el cliente sepa quién inició sesión, no solo “algún usuario autorizado.” La mayoría de los flujos modernos “Iniciar sesión con X” son OIDC, no OAuth puro.

Por qué PKCE es ahora obligatorio para clientes públicos: el flujo de código de autorización original de OAuth 2.0 asumía que el cliente podía guardar un secreto. Las aplicaciones móviles y las aplicaciones de una sola página no pueden — cualquiera puede desensamblar la aplicación y extraer el secreto incrustado. PKCE (Proof Key for Code Exchange, RFC 7636) reemplaza el secreto del cliente estático con un verificador aleatorio por flujo hasheado mediante SHA-256: el cliente envía el hash por adelantado y revela el texto plano solo al intercambiar el código, demostrando que es el mismo cliente que inició el flujo. PKCE es ahora obligatorio para todos los clientes públicos (OAuth 2.1, RFC 9700 BCP) y se recomienda también para clientes confidenciales como defensa en profundidad.

Los cuatro flujos que debes conocer y los dos que debes evitar: usa Código de Autorización + PKCE para casi todo (web, móvil, SPA). Usa Credenciales de Cliente para llamadas API máquina a máquina donde no hay usuario presente. El flujo Implícito (devuelve tokens de acceso directamente en fragmentos de URL) y el flujo de Credenciales de Propietario del Recurso (el cliente recoge la contraseña directamente) están ambos obsoletos en OAuth 2.1 — ninguno protege adecuadamente contra ataques modernos. Cualquier nueva integración OAuth debe rechazar estos aunque un proveedor los ofrezca. Relacionados: JWT, SAML. Referencia: RFC 6749 — OAuth 2.0, RFC 7636 — PKCE.

Ejemplo práctico

Un botón “Conectar Slack” en tu SaaS activa una redirección a https://slack.com/oauth/v2/authorize?client_id=...&scope=chat:write,channels:read&redirect_uri=https://app.example.com/oauth/callback&state=xyz&code_challenge=BASE64URL(SHA256(verifier))&code_challenge_method=S256. El usuario aprueba; Slack redirige a https://app.example.com/oauth/callback?code=ONE_TIME_CODE&state=xyz. Tu backend hace un POST a https://slack.com/api/oauth.v2.access con el código, el verificador PKCE original y el ID de cliente. Slack devuelve {"access_token": "xoxb-...", "scope": "chat:write,channels:read", "team": {"id": "T123"}}. Almacenas el token de acceso del lado del servidor (nunca en el almacenamiento local del navegador) y lo usas como Authorization: Bearer xoxb-... en las llamadas posteriores a la API de Slack. Todo el intercambio tarda unos cientos de milisegundos; el usuario ve una pantalla de consentimiento y nunca escribe una contraseña de Slack en tu aplicación.

Cuándo y por qué importa

Las configuraciones incorrectas de OAuth son una de las categorías más explotadas en la seguridad web moderna. Modos de fallo comunes: no validar el parámetro state (permite CSRF en el callback), permitir comodines en el registro de redirect_uri (permite el robo de tokens mediante redirección abierta), almacenar tokens de acceso en almacenamiento accesible al navegador (exfiltración por XSS) y tratar los tokens de actualización como tokens portadores de larga duración en lugar de rotarlos en cada uso. Las Mejores Prácticas Actuales de Seguridad de OAuth 2.0 (RFC 9700, publicado en 2025) codifican los valores predeterminados modernos: PKCE en todas partes, URIs de redirección con coincidencia exacta, tokens vinculados al remitente (DPoP o mTLS) para APIs de alto valor, y rotación de tokens de actualización con detección de reutilización. Seguir esto convierte la mayoría de los hallazgos de pruebas de penetración de OAuth en no-problemas. Referencia: RFC 9700 — BCP de Seguridad de OAuth 2.0.