Asegurar una REST API significa responder tres preguntas en cada request: quién eres (authentication), qué se te permite hacer (authorization), y es privado el canal (transport). Como REST es stateless, las credenciales deben viajar con cada request en lugar de vivir en una sesión del server.
Todo lo que sigue asume . Sin él, los tokens y las API keys viajan en texto plano y pueden ser esnifados. Esto no es negociable — un bearer token sobre HTTP es un token filtrado.
API keys — un secreto estático en una cabecera. Simple; bueno para server-to-server e identificar una aplicación, no a un usuario. Débil por sí sola (sin expiración, sin scope) a menos que se combine con más.
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
OAuth 2.0 — el estándar para el acceso delegado ("deja que la App X lea mis datos sin mi contraseña"). La app obtiene un access token mediante un flow (p. ej. Authorization Code) y lo envía como bearer token. Así es como funcionan "Sign in with Google" y las integraciones de terceros.
JWT (JSON Web Token) — un formato común para tokens: un token firmado y autocontenido que lleva claims (user id, roles, expiración). El server verifica la firma — sin necesidad de consultar la base de datos, lo que encaja con REST stateless.
header.payload.signature (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
La authentication prueba la identidad; la authorization decide el acceso. Los tokens llevan scopes (orders:read, orders:write) o roles; el server los comprueba por endpoint y devuelve 403 Forbidden cuando son insuficientes (vs 401 para auth ausente/inválida).
No/invalid token → 401 Unauthorized
Valid token, no scope → 403 Forbidden
✓ Access tokens de vida corta + refresh tokens (limitar el radio de impacto si se filtran)
✓ Rate limiting (429) para frenar el brute-force y el abuso
✓ Validar/sanitizar todo input; nunca confiar en el client
✓ Principio de mínimo privilegio en los scopes
La seguridad es donde un pequeño error se convierte en una brecha, así que los entrevistadores usan esto para ver si razonas sobre ella de forma estructural en lugar de recitar buzzwords. La señal que buscan es que separes las tres capas — transporte (HTTPS, siempre), autenticación (probar la identidad, de forma stateless, vía bearer tokens/JWT/OAuth), y autorización (scopes y mínimo privilegio) — y que no las confundas, p. ej. usando correctamente 401 para "no autenticado" frente a 403 para "autenticado pero no permitido". Las respuestas fuertes muestran conciencia de los compromisos prácticos: los JWTs son cómodos y stateless pero difíciles de revocar antes de que expiren (de ahí vidas cortas más refresh tokens), las API keys identifican apps no usuarios, y OAuth existe específicamente para que los usuarios no entreguen su contraseña a terceros. Atarlo a la naturaleza stateless de REST — credenciales en cada request, sin sesión de server — demuestra que entiendes por qué la seguridad de API tiene el aspecto que tiene.
Una biblioteca de preguntas de entrevista de IT con respuestas detalladas — de Junior a Senior.
Donar