OAuth 2.0 y OpenID Connect: La Guía Definitiva para Desarrolladores

Si alguna vez has integrado "Iniciar sesión con Google" o has accedido a una API en nombre de un usuario, te has encontrado con OAuth 2.0. A pesar de su omnipresencia, sigue siendo uno de los temas más incomprendidos en el desarrollo web. Términos como "Implicit Flow", "Bearer Token" y "OIDC" a menudo se lanzan al aire, lo que lleva a confusión y, lo que es peor, a vulnerabilidades de seguridad.

Esta guía pretende ser el recurso definitivo para entender OAuth 2.0 y OpenID Connect (OIDC), centrándose en lo que realmente necesitas saber para construir aplicaciones seguras.

Autenticación vs. Autorización

Antes de sumergirnos en los protocolos, debemos distinguir entre dos conceptos fundamentales:

Autenticación (AuthN): ¿Quién eres? (por ejemplo, verificar la identidad de un usuario).
Autorización (AuthZ): ¿Qué se te permite hacer? (por ejemplo, conceder acceso a un recurso).

OAuth 2.0 es un protocolo para la autorización. Permite que una aplicación acceda a recursos alojados por otro servidor en nombre de un usuario.
OpenID Connect (OIDC) es una capa construida sobre OAuth 2.0 específicamente para la autenticación. Permite a los clientes verificar la identidad del usuario.

Los Roles

Para entender los flujos, necesitas conocer a los jugadores:

Resource Owner (Propietario del Recurso): El usuario (tú).
Client (Cliente): La aplicación que intenta acceder a la cuenta del usuario (por ejemplo, una aplicación web).
Authorization Server (Servidor de Autorización): El servidor que presenta la pantalla de inicio de sesión y emite tokens (por ejemplo, Google, Auth0).
Resource Server (Servidor de Recursos): La API que aloja los datos del usuario.

Los Tokens

OAuth y OIDC dependen en gran medida de los tokens. Entender la diferencia es crucial.

Access Token (Token de Acceso)

Esta es la llave del castillo. El cliente envía este token al Servidor de Recursos para acceder a los datos. A menudo es un JWT (JSON Web Token), pero también puede ser una cadena opaca.

Propósito: Autorización.
Audiencia: Servidor de Recursos.

ID Token (Solo OIDC)

Este token contiene información sobre el usuario (nombre, correo electrónico, foto). Es estrictamente para que el Cliente identifique al usuario.

Propósito: Autenticación.
Audiencia: Cliente.
Formato: Siempre un JWT.

Refresh Token (Token de Actualización)

Un token de larga duración utilizado para obtener nuevos Access Tokens cuando el actual expira. Esto permite al usuario permanecer conectado sin volver a introducir credenciales.

Consejo: Depurar JWTs puede ser un dolor de cabeza. Utiliza el Decodificador JWT de Pockit para inspeccionar el encabezado y la carga útil de tus tokens de forma segura sin que salgan de tu navegador.

Flujos Comunes (Tipos de Concesión)

El "Grant Type" determina cómo el cliente obtiene el Access Token. Elegir el incorrecto es un riesgo de seguridad común.

1. Authorization Code Flow (con PKCE)

Mejor para: Apps del lado del servidor, SPAs y Apps móviles.
Este es el estándar de oro. En lugar de obtener un token directamente, el cliente obtiene un "código" temporal que intercambia por un token. PKCE (Proof Key for Code Exchange) añade una capa de seguridad, evitando ataques de intercepción de código.

El cliente redirige al usuario al Servidor de Autorización.
El usuario inicia sesión y aprueba el acceso.
El Servidor de Autorización redirige de vuelta al Cliente con un code.
El cliente intercambia el code + code_verifier por un Access Token.

2. Client Credentials Flow

Mejor para: Comunicación Máquina a Máquina (M2M).
Se utiliza cuando una aplicación necesita acceder a sus propios recursos, no a los de un usuario. No hay interacción del usuario.

El cliente envía client_id y client_secret al Servidor de Autorización.
El Servidor de Autorización devuelve un Access Token.

3. Implicit Flow (Obsoleto)

Mejor para: Nada (Históricamente usado para SPAs).
Este flujo devuelve tokens directamente en el fragmento de la URL. Ahora se considera inseguro debido al riesgo de fuga de tokens en el historial del navegador y los registros. No uses esto.

Solución de Problemas Comunes

"redirect_uri_mismatch"

Este es el error más común. La redirect_uri que envías en la solicitud debe coincidir exactamente con una de las URIs permitidas en el panel de control de tu proveedor de OAuth. Incluso una barra final hace la diferencia.

"invalid_grant"

Este error genérico suele significar:

El código de autorización ha expirado (tienen una vida muy corta).
El código ya ha sido usado.
La redirect_uri usada para obtener el código no coincide con la usada para intercambiarlo.

Conclusión

OAuth 2.0 y OIDC son herramientas poderosas que forman la columna vertebral de la identidad moderna. Al entender la distinción entre AuthN y AuthZ, elegir el flujo correcto (¡Auth Code con PKCE!), y saber cómo inspeccionar tus tokens, puedes construir aplicaciones seguras y robustas.

No inventes tu propia criptografía, y no intentes reinventar la autenticación. Cíñete a los estándares, y tus usuarios (y tu equipo de seguridad) te lo agradecerán.