OAuth 2.0 explicado con diagramas: roles, PKCE y tokens

OAuth 2.0 es el estándar que permite a una aplicación acceder a recursos en nombre de un usuario sin manejar su contraseña. Cuando pulsas «Iniciar sesión con Google», OAuth2 está trabajando por detrás. En este artículo desmontamos sus piezas, seguimos el flujo más usado hoy (Authorization Code + PKCE) y aterrizamos buenas prácticas de seguridad.

Qué problema resuelve

Antes de OAuth, si una app quería leer tu correo tenías que darle tu usuario y contraseña. Eso significa entregar las llaves de toda tu cuenta a un tercero. OAuth2 introduce una idea simple: en lugar de compartir la credencial, se entrega un token de acceso limitado en alcance y tiempo. El usuario delega un permiso concreto (por ejemplo «leer mi calendario») sin exponer su clave.

💡 OAuth2 autoriza, no autentica

OAuth 2.0 es un protocolo de autorización (qué puede hacer una app). Para autenticación (quién eres) se usa OpenID Connect (OIDC), que añade un id_token sobre OAuth2. Confundirlos es el error más común.

Los cuatro roles

Todo el modelo gira en torno a cuatro actores:

Resource Owner: el usuario dueño de los datos.
Client: la aplicación que quiere acceder a esos datos.
Authorization Server: emite los tokens tras autenticar al usuario y obtener su consentimiento.
Resource Server: la API que guarda los recursos y valida el token.

Los cuatro roles de OAuth 2.0 y cómo se relacionan.

El flujo recomendado: Authorization Code + PKCE

Existen varios «grant types», pero para apps web, móviles y SPAs el estándar actual es Authorization Code con PKCE (Proof Key for Code Exchange). PKCE evita que un atacante que intercepte el código de autorización pueda canjearlo por tokens.

Cómo funciona PKCE

El cliente genera un secreto aleatorio (code_verifier) y envía su hash (code_challenge) al pedir autorización. Al canjear el código, debe presentar el code_verifier original. Solo quien inició el flujo lo conoce.

Authorization Code + PKCE, paso a paso.

El intercambio de token

El paso 5 (canje del código) se ve así:

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

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https://app.example.com/callback
&client_id=s6BhdRkqt3
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

Y la respuesta entrega los tokens:

{
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
  "id_token": "eyJhbGciOiJSUzI1NiIs..."
}

Access token vs refresh token

Access token: de vida corta (minutos). Se envía en cada request como Authorization: Bearer …. Si se filtra, expira pronto.
Refresh token: de vida larga. Sirve para obtener nuevos access tokens sin volver a pedir login. Debe guardarse con máxima protección.

Buenas prácticas de seguridad

Usa siempre Authorization Code + PKCE. El flujo Implicit está obsoleto.
Registra redirect_uri exactas y valida el parámetro state para prevenir CSRF.
Access tokens de vida corta; rota y revoca refresh tokens.
Pide solo los scopes mínimos necesarios.
Nunca expongas el client_secret en clientes públicos (SPA/móvil).

✅ Regla de oro

Menor alcance, menor duración, menor superficie. Un token debe poder hacer lo mínimo, durante el mínimo tiempo, con la mínima exposición.

En resumen

OAuth2 delega acceso mediante tokens en lugar de compartir credenciales. Los cuatro roles reparten responsabilidades, y el flujo Authorization Code + PKCE es hoy el camino seguro por defecto. Si además necesitas identidad del usuario, súmale OpenID Connect.