Cada vez que implementas o interactúas con botones como "Iniciar sesión con Google" o "Acceder con GitHub", estás utilizando el protocolo OAuth 2.0 de forma interna. Convertido en el estándar indiscutible de la industria para gestionar autorizaciones, su combinación con la capa de OpenID Connect (OIDC) permite resolver también la autenticación de identidad. Para cualquier desarrollador que construya aplicaciones conectadas o integraciones con servicios de terceros, dominar el funcionamiento de estos protocolos es una habilidad imprescindible de ciberseguridad.

Autenticación frente a Autorización: ¿Cuál es la diferencia?

  • Autenticación (AuthN): Responde a la pregunta "¿Quién eres tú?". Se encarga de verificar y validar la identidad del usuario en el sistema. De esto se ocupa principalmente OpenID Connect.
  • Autorización (AuthZ): Responde a la pregunta "¿Qué tienes permitido hacer?". Consiste en conceder permisos específicos para acceder a recursos sin revelar credenciales. Este es el terreno de OAuth 2.0.

OAuth 2.0 nació exclusivamente con fines de autorización, permitiendo que una plataforma externa acceda a tus archivos de Google Drive o listas de reproducción sin necesidad de conocer tu contraseña de Google. Para subsanar la falta de identidad del usuario, se introdujo OpenID Connect como una capa superior estandarizada encargada de suministrar la información de perfil del usuario de forma estructurada.

Los Actores Clave en el Flujo de OAuth

  • Propietario del Recurso (Resource Owner): El usuario final que posee los datos y tiene el poder de conceder acceso a ellos.
  • Cliente (Client): La aplicación web o móvil (la que tú estás desarrollando) que solicita interactuar con los recursos del usuario.
  • Servidor de Autorización (Authorization Server): El motor que autentica al usuario, gestiona los consentimientos y emite los tokens de seguridad (por ejemplo, los servidores de Auth0, Google o GitHub).
  • Servidor de Recursos (Resource Server): La API que almacena y protege la información privada del usuario (como la API de Google Contacts o la API de GitHub).

Flujo de Código de Autorización con PKCE (El Estándar Recomendado)

Hoy en día, el flujo de código de autorización es la opción por defecto para aplicaciones web del lado del servidor, aplicaciones de una sola página (SPAs) y apps móviles. El uso de PKCE (Proof Key for Code Exchange) es obligatorio para mitigar ataques de interceptación de código, añadiendo un secreto dinámico generado en cada flujo.

Paso a Paso del Flujo
1. El usuario hace clic en "Iniciar sesión con Google" en tu aplicación.
2. Tu aplicación redirige al usuario al endpoint de autorización de Google:
   GET https://accounts.google.com/o/oauth2/v2/auth?
     response_type=code
     &client_id=TU_CLIENT_ID
     &redirect_uri=https://tuapp.com/callback
     &scope=openid email profile
     &state=token_csrf_aleatorio
     &code_challenge=HASH_SHA256
     &code_challenge_method=S256

3. El usuario se autentica en Google y aprueba los permisos solicitados.
4. Google redirige al usuario de vuelta a tu aplicación con un código temporal:
   GET https://tuapp.com/callback?code=CODIGO_AUTORIZACION&state=token_csrf_aleatorio

5. Tu servidor intercambia de forma segura el código por los tokens finales:
   POST https://oauth2.googleapis.com/token
   Body: {
     code: CODIGO_AUTORIZACION,
     client_id: TU_CLIENT_ID,
     client_secret: TU_CLIENT_SECRET,
     redirect_uri: https://tuapp.com/callback,
     grant_type: authorization_code,
     code_verifier: CADENA_ALEATORIA_ORIGINAL
   }

6. El servidor de autorización responde con los tokens:
   {
     "access_token": "ya29.a0...",
     "id_token": "eyJhbGci...",       // Aportado por OpenID Connect
     "refresh_token": "1//0e...",
     "expires_in": 3600,
     "token_type": "Bearer"
   }

Tipos de Tokens y su Utilidad

  • Token de Acceso (Access Token): Credencial de corta duración (usualmente de 1 hora) diseñada para autorizar peticiones HTTP directas a las APIs protegidas. Se envía en la cabecera Authorization: Bearer <token>.
  • Token de Actualización (Refresh Token): Credencial de larga duración que permite solicitar nuevos tokens de acceso en segundo plano cuando los anteriores expiran, evitando que el usuario deba iniciar sesión constantemente. Debe almacenarse con extrema seguridad (idealmente solo en el servidor).
  • ID Token: Un token web JSON (JWT) estructurado que transporta la información de perfil del usuario autenticado (nombre, avatar, correo). Es el elemento central introducido por OpenID Connect.

Ámbitos (Scopes): Delimitando los Permisos

Los ámbitos representan los permisos específicos que tu aplicación solicita sobre la cuenta del usuario. Estos se muestran con total transparencia en la pantalla de consentimiento antes de que el usuario apruebe el acceso.

Ejemplos Comunes de Scopes
// Ámbitos de OpenID Connect
openid        // Requerido obligatoriamente para OIDC
email         // Acceso a la dirección de correo electrónico
profile       // Información básica (nombre, foto, idioma)

// Ámbitos específicos de Google
https://www.googleapis.com/auth/drive.readonly
https://www.googleapis.com/auth/calendar

// Ámbitos específicos de GitHub
read:user     // Lectura del perfil del usuario
repo          // Acceso total a repositorios privados y públicos
read:org      // Ver membresías de organizaciones

Prácticas de Seguridad Indispensables para Implementar OAuth 2.0

  • Implementar PKCE siempre: Es fundamental tanto para aplicaciones móviles y SPAs como para servidores convencionales para evitar la interceptación de flujos.
  • Validar rigurosamente el parámetro state: Actúa como un mecanismo de protección indispensable contra ataques de falsificación de solicitudes en sitios cruzados (CSRF).
  • Evitar el almacenamiento local desprotegido: Nunca guardes tokens sensibles en localStorage o sessionStorage. Opta por cookies seguras con atributos HTTP-only, Secure y SameSite.
  • Efectuar la validación de ID Tokens: Comprueba siempre la firma criptográfica, la fecha de expiración y que el emisor coincida con tu proveedor de identidad.
  • Seguir el principio de mínimo privilegio: Solicita exclusivamente los scopes mínimos necesarios para el funcionamiento de la aplicación web.
  • Configurar rotación de Refresh Tokens: Limita el ciclo de vida de los tokens de actualización para neutralizar robos de credenciales en reposo.

Tipos de Concesiones (Grants): ¿Cuál elegir para cada escenario?

  • Authorization Code + PKCE: El estándar ideal para la gran mayoría de aplicaciones modernas (SPAs, SSR, móviles).
  • Client Credentials: Para integraciones puras de servidor a servidor donde no interviene un usuario humano directo.
  • Device Code: Diseñado específicamente para entornos limitados de entrada de datos como Smart TVs, terminales CLI o dispositivos IoT.
  • ⚠️ Flujo Implícito (Implicit Flow): Completamente obsoleto y desaconsejado por motivos graves de seguridad en la actualidad. No lo utilices.

Prueba Nuestras Herramientas Gratuitas para Desarrolladores

Decodifica y analiza la estructura de tokens JWT y cadenas codificadas en Base64.