OAuth 2.0

OAuth 2.0 es un marco (framework) de autorización delegada. En lugar de darle tu contraseña a una app, apruebas una solicitud en un servidor de autorización, que emite para la app un token de acceso limitado por alcance (scope, por ejemplo orders:read) y por tiempo. La app envía ese token a la API, normalmente como Authorization: Bearer <token>. Los cuatro roles son el propietario del recurso (el usuario), el cliente (la app), el servidor de autorización (emite los tokens) y el servidor de recursos (la API).

Autenticación frente a autorización

La autenticación responde a “¿quién eres?”. La autorización responde a “¿qué tienes permitido hacer?”. OAuth 2.0 por sí solo trata de autorización: un token de acceso indica a qué puede acceder su portador, no quién es el usuario de forma fiable. Iniciar sesión de usuarios es tarea de OpenID Connect, una capa sobre OAuth 2.0 que añade un ID token (un JWT) que describe al usuario. Los botones “Iniciar sesión con…” usan OpenID Connect.

Tipos de concesión (grant types) habituales

• Código de autorización con PKCE: para apps que actúan en nombre de un usuario, incluidas apps de navegador y móviles. El usuario inicia sesión en el servidor de autorización, la app recibe un código de corta duración y lo intercambia por tokens.
• Credenciales de cliente (client credentials): para llamadas entre servicios sin usuario. Es el flujo que más usan las suites de pruebas de API.
• Refresh token: intercambia un refresh token de larga duración por un nuevo token de acceso.

Las concesiones implícita y de contraseña del propietario del recurso están desaconsejadas por las guías de seguridad actuales de OAuth y se eliminan en el borrador de OAuth 2.1.

Ejemplo: credenciales de cliente

curl -X POST https://auth.example.com/oauth/token \
  -d grant_type=client_credentials \
  -d client_id="$CLIENT_ID" \
  -d client_secret="$CLIENT_SECRET" \
  -d scope=orders:read

La respuesta contiene un access_token, un token_type con valor Bearer y un expires_in en segundos. Obtén el token una sola vez en un fixture, guárdalo en caché hasta que esté a punto de caducar y mantén los secretos del cliente en los secretos de CI, no en el repositorio.

Qué probar

• Un token ausente, caducado o mal formado devuelve 401.
• Un token válido sin el scope necesario devuelve 403.
• Se rechazan los tokens emitidos para otra audiencia u otro cliente.
• En el flujo de código de autorización, se comprueba el parámetro state y la URI de redirección debe coincidir exactamente con un valor registrado.
• Las respuestas de token y las redirecciones nunca exponen tokens en logs ni en URLs.