Token de identificación: JWT

Continuemos donde lo dejamos en los dos primeros capítulos (Descripción general de OAuth2 y Comprensión de OpenID Connect) y comencemos a comprender JWT. Primero, repasemos brevemente OAuth2 y OpenID:

OpenID se basa en OAuth con capacidades completas de autenticación y autorización. Los resultados de la autenticación y la autorización se reflejan en la etiqueta de identificación, y la etiqueta de identificación suele ser un JWT, entonces, ¿por qué un JWT? Expliquemos uno por uno a través de los siguientes puntos.

JWT RFC 7519 proporciona la definición oficial de algunos campos:

Por supuesto, no se limita a esto, puede agregar otros campos según sus necesidades. En este punto, podemos ver que JWT proporciona la funcionalidad necesaria para las etiquetas de identificación. Un JTW completo consta de tres partes: encabezado, carga útil y firma. Los campos de autenticación y autorización que acabamos de mencionar están presentes en la carga útil.

El encabezado contiene los metadatos de JTW, incluido el algoritmo de firma y el tipo de token, de la siguiente manera:

La parte de la firma es la firma de las dos primeras partes para evitar que los datos sean manipulados. con. Primero, es necesario especificar una clave (secreta). Esta clave sólo la conoce el servidor y no puede revelarse al usuario. Luego, utilizando el algoritmo de firma especificado en el encabezado (el valor predeterminado es HMAC SHA256), se genera una firma de acuerdo con la siguiente fórmula.

Después de calcular la firma, base64 serializa las tres partes del encabezado, la carga útil y la firma en tres cadenas, luego presiona estas tres cadenas y luego concatena estas tres cadenas en una sola y las devuelve al cliente.

Los tokens de identificación deben ser seguros, ¿cómo hace esto JWT?

Acabamos de ver la parte de la firma. La firma es solo para evitar que se manipulen los datos. JWT no está cifrado de forma predeterminada, pero se puede cifrar. Una vez generado el token original, se puede volver a cifrar utilizando la clave secreta. Por ejemplo, el servidor de autenticación cifra el token con la clave privada y distribuye la clave pública a otros servidores de aplicaciones. El servicio de aplicaciones obtiene el token cifrado y lo descifra con la clave pública para obtener el JWT y luego utiliza la clave secreta firmada para. verificar que los datos no hayan sido alterados.

Veamos algunas otras alternativas: Simple Web Markup (SWT) y Security Assertion Markup Language markup (SAML).

JWT vs SAML:

JWT vs SWT: En términos de seguridad, SWT solo admite cifrado simétrico, mientras que JWT y SAML admiten cifrado de clave pública-privada.

Como desarrollador móvil, también me gustaría comparar el modelo de token simple original en SSO con JWT:

Antes de usar este mecanismo, generalmente usábamos una cadena generada aleatoriamente. como un token, que se devuelve al front-end después de una verificación exitosa, y luego el front-end llevará este token consigo en cada solicitud. No hay problema cuando el servicio de backend es una sola aplicación. Cuando llega la solicitud, el token de verificación es válido, pero ¿qué debemos hacer cuando el servicio de verificación está separado de otros servicios de aplicación? Después de solicitar el servicio de la aplicación, inicia una solicitud al servicio de autenticación para verificar si el token es válido y si tiene permiso para acceder al servicio de la aplicación. No hay nada de malo en hacer esto, pero cuando hay muchos servicios, como los microservicios, inevitablemente ejercerá demasiada presión sobre el servidor de autenticación.

Utilizando este mecanismo, el cliente inicia sesión a través del servicio de autenticación, obtiene un JWT y luego otros servicios de aplicaciones pueden verificar por sí mismos que el token es válido y tiene acceso.

Esto parece perfecto, pero tiene sus propios problemas. Veamos un escenario: cambios de permisos.

Un usuario que originalmente era un superadministrador con acceso a todos los servicios y la capacidad de eliminar o cambiar cualquier servicio, obtuvo un JWT en este estado y luego cambió sus permisos a un administrador normal, por lo que no debería tener todos los permisos, pero sí el JWT que comenzó a usar está almacenado en caché en el lado del cliente y todavía está disponible; otros servicios no tienen forma de saber que los permisos del usuario han cambiado. Las consecuencias se pueden imaginar. La solución a este problema es establecer el período de validez del token en un período de tiempo más corto.