OAuth 2.0

Definición

OAuth 2.0 (Open Authorization 2.0) es un framework de autorización estándar de la industria que permite a aplicaciones de terceros obtener acceso limitado a cuentas de usuario en un servicio HTTP sin exponer las credenciales del usuario.

A diferencia de OAuth 1.0, OAuth 2.0 se enfoca exclusivamente en autorización (no autenticación), delegando el proceso de autenticación a protocolos separados como OpenID Connect.

Contexto

OAuth 2.0 fue diseñado para resolver el problema de compartir credenciales. Antes de OAuth, los usuarios tenían que compartir sus contraseñas con aplicaciones de terceros para otorgar acceso a sus datos—un grave riesgo de seguridad.

Conceptos Clave

  • Resource Owner (Propietario del Recurso): El usuario que posee los datos
  • Client (Cliente): La aplicación que solicita acceso
  • Resource Server (Servidor de Recursos): La API que aloja recursos protegidos
  • Authorization Server (Servidor de Autorización): Emite tokens de acceso después de autenticar al usuario

Ejemplo

Un flujo típico de OAuth 2.0 (Authorization Code Grant):

  1. El usuario hace clic en “Iniciar sesión con Google” en la App A
  2. App A redirige al servidor de autorización de Google
  3. El usuario inicia sesión y consiente los permisos solicitados
  4. Google redirige de vuelta a App A con un código de autorización
  5. App A intercambia el código por un token de acceso
  6. App A usa el token para acceder a las APIs de Google en nombre del usuario

Código

Solicitud de Autorización

GET /authorize?response_type=code
    &client_id=abc123
    &redirect_uri=https://app.example.com/callback
    &scope=read:profile
    &state=xyz789 HTTP/1.1
Host: auth.example.com

Intercambio de Token

POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=AUTH_CODE_HERE
&redirect_uri=https://app.example.com/callback
&client_id=abc123
&client_secret=secret456

Uso del Token de Acceso

GET /api/user/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer ACCESS_TOKEN_HERE

Diagrama

sequenceDiagram
    participant Usuario
    participant Cliente as App Cliente
    participant AuthServer as Servidor Autorización
    participant ResourceServer as Servidor Recursos

    Usuario->>Cliente: 1. Iniciar login
    Cliente->>AuthServer: 2. Solicitud autorización
    AuthServer->>Usuario: 3. Login y consentimiento
    Usuario->>AuthServer: 4. Aprobar
    AuthServer->>Cliente: 5. Código autorización
    Cliente->>AuthServer: 6. Intercambiar código por token
    AuthServer->>Cliente: 7. Token de acceso
    Cliente->>ResourceServer: 8. Petición API con token
    ResourceServer->>Cliente: 9. Recurso protegido

Mejores Prácticas

  1. Siempre usar HTTPS - OAuth 2.0 requiere cifrado TLS
  2. Usar PKCE (Proof Key for Code Exchange) para clientes públicos
  3. Tokens de acceso de corta duración - Expiran en 1 hora o menos
  4. Refresh tokens para sesiones largas - Almacenar de forma segura
  5. Validar URIs de redirección - Prevenir interceptación de código
  6. Usar parámetro state - Prevenir ataques CSRF
  7. Limitar scopes - Solicitar permisos mínimos necesarios
  8. Rotar client secrets - Actualizar credenciales regularmente

Errores Comunes

  1. Usar implicit flow - Obsoleto, usar Authorization Code + PKCE
  2. Almacenar tokens en localStorage - Vulnerabilidad XSS, usar cookies httpOnly
  3. No validar parámetro state - Riesgo CSRF
  4. Scopes demasiado amplios - Principio de mínimo privilegio
  5. Exponer client secrets - Mantener solo en backend
  6. No usar refresh tokens - Mala UX con re-auth frecuente

Analogía

OAuth 2.0 es como una llave de valet para tu coche:

  • Tú (propietario del recurso) das al valet (cliente) una llave especial
  • La llave de valet (token de acceso) solo puede conducir el coche, no abrir el maletero (scope limitado)
  • El valet no puede hacer una copia de tu llave maestra (no compartir contraseña)
  • La llave expira después de unas horas (expiración de token)
  • Puedes revocar la llave en cualquier momento (revocación de token)

Seguridad

Amenazas

  • Interceptación de código de autorización - Mitigar con PKCE
  • Fuga de tokens - Usar tokens de corta duración + rotación de refresh
  • Ataques CSRF - Validar parámetro state
  • Phishing - Educar usuarios sobre pantallas de auth legítimas
  • Ataques de replay - Usar nonces y token binding

Recomendaciones

  • Implementar rotación de tokens para refresh tokens
  • Usar JWT para tokens autocontenidos con verificación de firma
  • Habilitar rate limiting en endpoints de tokens
  • Monitorear patrones de acceso anómalos
  • Implementar listas de revocación de tokens

Términos Relacionados

Categoría: Autenticación y Seguridad Dificultad: Intermedio Última Actualización: 6 de enero de 2025

Also available in: