OAuth 2.1

Definition

OAuth 2.0 se lanzó en 2012, y más de una década de ataques reales e investigación de seguridad nos ha enseñado qué características opcionales eran realmente esenciales. OAuth 2.1 es la versión “aprendimos las lecciones” - toma todas esas recomendaciones de “realmente deberías hacer esto” y las hace obligatorias. Si OAuth 2.0 era una casa con cerraduras opcionales en algunas puertas, OAuth 2.1 es la misma casa donde cada puerta está cerrada y ni siquiera puedes comprar una sin cerraduras.

El cambio más grande es que PKCE (Proof Key for Code Exchange) ahora es obligatorio para todos, no solo para apps móviles. Aprendimos por las malas que los códigos de autorización pueden ser interceptados por apps maliciosas, extensiones de navegador, o ataques man-in-the-middle. PKCE previene esto probando que el mismo cliente que inició la autorización es el que la está completando. OAuth 2.1 también elimina completamente el flujo implícito, que era un atajo conveniente que resultó ser una pesadilla de seguridad - ponía tokens de acceso directamente en URLs donde podían filtrarse a través del historial del navegador, headers de referencia, o logs del servidor.

Piensa en OAuth 2.1 como seguridad-por-defecto en lugar de seguridad-si-te-acuerdas. Elimina las opciones peligrosas que parecían convenientes pero causaron brechas. No más flujo implícito. No más aceptar contraseñas en claro (el grant de password también se fue). La rotación de refresh tokens es fuertemente recomendada. El matching exacto de redirect URI es obligatorio - no más wildcards que los atacantes podrían explotar. Para los desarrolladores, esto realmente simplifica las cosas: menos decisiones que tomar, menos formas de equivocarse, y alineación automática con las mejores prácticas de seguridad actuales.

Example

OAuth 2.1 refleja lecciones duramente aprendidas de incidentes de seguridad en toda la industria:

Autenticación en Apps Móviles: Antes de OAuth 2.1, los desarrolladores de apps móviles tenían que decidir si implementar PKCE - muchos no lo hacían porque parecía trabajo extra. Esto llevó a ataques de robo de códigos de autorización donde apps maliciosas podían interceptar códigos. Ahora, una app bancaria implementando OAuth 2.1 usa PKCE automáticamente, protegiendo a los usuarios incluso si accidentalmente instalan una app maliciosa que intenta interceptar flujos de login.

Aplicaciones de Página Única (SPAs): Las apps JavaScript comúnmente usaban el flujo implícito porque era más simple - solo obtener el token en la redirección URL. Pero esos tokens terminaban en el historial del navegador, eran registrados por scripts de analytics, y se filtraban a través de headers de referencia. Una SPA moderna siguiendo OAuth 2.1 usa flujo de código de autorización con PKCE, manteniendo los tokens fuera de URLs por completo y almacenándolos de forma segura.

Integraciones de Terceros: Cuando tu sistema de RRHH se integra con Slack o Salesforce, el matching más estricto de redirect URI de OAuth 2.1 previene una clase de ataques donde los hackers registran dominios de apariencia similar. En lugar de aceptar https://tuempresa.com/*, OAuth 2.1 requiere matching exacto como https://tuempresa.com/oauth/callback - sin wildcards, sin manipulación de rutas.

Proveedores de Identidad Empresarial: Empresas como Okta, Auth0 y Azure AD han actualizado sus servicios para soportar OAuth 2.1. Cuando configuras una nueva aplicación, te guían hacia patrones OAuth 2.1 y advierten contra (o bloquean) flujos deprecados. Esto significa que incluso desarrolladores no familiarizados con seguridad OAuth quedan protegidos por defecto.

Proveedores de API: Empresas como Stripe y Twilio que ofrecen integraciones basadas en OAuth están adoptando OAuth 2.1 para proteger a sus clientes. Un partner construyendo una integración con Stripe obtiene automáticamente seguridad moderna sin tener que convertirse en un experto en OAuth.

Analogía

El Código de Construcción Actualizado: OAuth 2.0 era como un código de construcción que decía “probablemente deberías instalar detectores de humo.” OAuth 2.1 es el código actualizado que dice “los detectores de humo son obligatorios, y no emitimos permisos sin ellos.” Las características de seguridad que eran recomendaciones opcionales ahora son requisitos legales porque demasiados edificios se incendiaron.

La Evolución de Seguridad del Automóvil: Los primeros coches tenían cinturones de seguridad opcionales - mucha gente no los usaba. Los coches modernos requieren cinturones, tienen airbags por todas partes, y no paran de pitar hasta que te abrochas. OAuth 2.1 es como la seguridad moderna del automóvil: las características que salvan vidas ya no son opcionales porque tenemos décadas de datos de accidentes probando que funcionan.

La Actualización de Medicamento con Receta: A veces un medicamento que estaba disponible sin receta pasa a ser solo con receta después de que aprendemos sobre efectos secundarios o potencial de abuso. OAuth 2.1 es similar - la característica del “flujo implícito” estaba libremente disponible, pero después de años de incidentes de seguridad, ha sido retirada de los estantes por completo.

El Código Sanitario del Restaurante: Un restaurante podía decir “deberías lavarte las manos antes de manipular comida.” Luego los inspectores sanitarios lo hicieron obligatorio después de que suficiente gente se enfermó. OAuth 2.1 toma las prácticas de seguridad que se sugerían y las convierte en requisitos inspeccionables - no puedes pasar la auditoría de seguridad sin ellos.

Diagrama

flowchart TB
    subgraph OAuth2["OAuth 2.0 (2012)"]
        direction TB
        AC1[Flujo Authorization Code]
        IMP[Flujo Implícito]
        PWD[Grant de Password]
        CC1[Client Credentials]
        PKCE1[PKCE - Opcional]
        RR1[Rotación Refresh - Opcional]
        RU1[Redirect URI - Wildcards OK]
    end

    subgraph OAuth21["OAuth 2.1 (Mejores Prácticas Actuales)"]
        direction TB
        AC2[Flujo Authorization Code]
        CC2[Client Credentials]
        PKCE2[PKCE - OBLIGATORIO]
        RR2[Rotación Refresh - Recomendado]
        RU2[Redirect URI - Solo Coincidencia Exacta]
    end

    OAuth2 -->|Evolución| OAuth21

    IMP -.->|ELIMINADO| X1[❌]
    PWD -.->|ELIMINADO| X2[❌]
    PKCE1 -->|Ahora Requerido| PKCE2
    RR1 -->|Fuertemente Recomendado| RR2
    RU1 -->|Más Estricto| RU2

    style IMP fill:#ff6b6b,color:#fff
    style PWD fill:#ff6b6b,color:#fff
    style X1 fill:#ff6b6b,color:#fff
    style X2 fill:#ff6b6b,color:#fff
    style PKCE2 fill:#51cf66,color:#fff
    style RU2 fill:#51cf66,color:#fff

Code Example

// OAuth 2.1 - PKCE es obligatorio para todos los flujos
const crypto = require('crypto');

// Generar desafío PKCE
function generatePKCE() {
  const verifier = crypto.randomBytes(32).toString('base64url');
  const challenge = crypto
    .createHash('sha256')
    .update(verifier)
    .digest('base64url');

  return { verifier, challenge };
}

// 1. Iniciar autorización con PKCE (requerido en OAuth 2.1)
const { verifier, challenge } = generatePKCE();
sessionStorage.setItem('pkce_verifier', verifier);

const authUrl = new URL('https://oauth.provider.com/authorize');
authUrl.searchParams.append('response_type', 'code');
authUrl.searchParams.append('client_id', 'your_client_id');
authUrl.searchParams.append('redirect_uri', 'https://yourapp.com/callback');
authUrl.searchParams.append('code_challenge', challenge);
authUrl.searchParams.append('code_challenge_method', 'S256');
authUrl.searchParams.append('scope', 'read:user');
authUrl.searchParams.append('state', generateRandomState());

window.location.href = authUrl.toString();

// 2. Intercambiar código con verificador PKCE
const tokenResponse = await fetch('https://oauth.provider.com/token', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    grant_type: 'authorization_code',
    code: authorizationCode,
    client_id: 'your_client_id',
    redirect_uri: 'https://yourapp.com/callback',
    code_verifier: sessionStorage.getItem('pkce_verifier')
  })
});

Notas de Seguridad

Estándares y RFCs