Seguridad: OAuth y JWT

REST no trae seguridad propia: no forma parte del estilo. Lo que se hace es combinar mecanismos que ya existen en HTTP y alrededor de HTTP, y lo primero es tener claro qué resuelve cada uno, porque el examen mezcla las columnas.

HTTP Basic merece un aviso: las credenciales van codificadas en base64, que no es cifrado sino una simple representación en texto. Cualquiera que vea el tráfico las lee, así que Basic sin TLS por debajo equivale a enviar la contraseña en claro.

Los mecanismos se acumulan, no se eligen: TLS protege el canal y por dentro viaja el testigo que identifica y autoriza. Uno no sustituye al otro.

OAuth 2.0 resuelve un problema concreto: que una aplicación pueda acceder a los recursos de un usuario en otro servicio sin conocer su contraseña. El usuario se autentica ante el proveedor, este emite un testigo de acceso limitado en alcance y en tiempo, y la aplicación presenta ese testigo en cada llamada.

Conviene decirlo con precisión porque es la trampa habitual: OAuth 2.0 es un marco de autorización delegada, no un protocolo de autenticación. Quien añade la autenticación de usuarios sobre él es OpenID Connect, que es una capa construida encima.

El testigo se envía en la cabecera Authorization con el esquema Bearer, que significa literalmente «al portador»: quien lo lleva, lo usa. De ahí que un testigo Bearer robado sirva a quien lo roba, y de ahí que TLS no sea opcional.

GET /api/alumnos/482/falladas HTTP/1.1
Host: api.llegandoalcorte.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI0ODIi...
Accept: application/json

OAuth 2.0 autoriza, no autentica. Si una pregunta define OAuth como «autenticación basada en token», está describiendo el uso corriente, no el estándar.

JWT (JSON Web Token) es un formato de testigo compacto, pensado para viajar en una cabecera HTTP. Tiene tres partes separadas por puntos: cabecera, carga y firma. Cada una es un objeto JSON codificado en base64, salvo la firma, que es el resultado del cálculo criptográfico.

cabecera . carga . firma

cabecera   { "alg": "HS256", "typ": "JWT" }

carga      { "sub": "482",
             "iat": 1786000000,
             "exp": 1786003600,
             "plan": "largo" }

firma      HMAC-SHA256(
             base64url(cabecera) + "." + base64url(carga),
             clave secreta que solo conoce el servidor )

La cabecera declara el algoritmo con el que se ha firmado. El servidor calcula la firma sobre la cabecera y la carga usando una clave que solo él conoce, y al recibir el testigo repite el cálculo: si coincide, el contenido no se ha tocado. Así puede confiar en el testigo sin haber guardado nada, que es justo lo que necesita un servicio sin estado.

La carga está codificada, no cifrada: cualquiera puede leerla. La firma impide modificarla, no impide verla, así que en un JWT no se meten datos sensibles.

Los datos que van en la carga de un JWT se llaman claims: afirmaciones sobre el sujeto del testigo. Unos están registrados y significan lo mismo en todas partes, y otros los define la aplicación para sus propias necesidades, como el plan contratado o el papel del usuario.

Como el servicio no guarda sesión, el cliente tiene que enviar el testigo en todas y cada una de las peticiones: no hay nada al otro lado que recuerde que ya se identificó hace un minuto. Esa es la consecuencia práctica más visible de que REST sea sin estado, y también su punto débil, porque un testigo emitido no se puede retirar antes de que expire salvo que se monte una lista de revocación, que es precisamente volver a guardar estado.