JSON Web Token (abreviado como JWT) es actualmente la solución de autenticación entre dominios más popular. Este artículo presenta su principio y uso.
1. El problema de la autenticación entre dominios.
Los servicios de Internet son inseparables de la autenticación de usuarios. El proceso general es el siguiente.
1. El usuario envía el nombre de usuario y la contraseña al servidor.
2. Una vez autenticado el servidor, guarde los datos relevantes en la sesión actual (sesión), como la función del usuario, la hora de inicio de sesión, etc.
3. El servidor devuelve un session_id al usuario y lo escribe en la cookie del usuario.
4. Para cada solicitud posterior del usuario, el session_id se enviará de regreso al servidor a través de la cookie.
5. El servidor recibe el session_id, encuentra los datos guardados en el período anterior y así conoce la identidad del usuario.
El problema de este modelo es que la escalabilidad (scaling) no es buena. Por supuesto, no hay problema con una sola máquina: si se trata de un clúster de servidores o una arquitectura orientada a servicios entre dominios, se requiere compartir datos de sesión y cada servidor puede leer la sesión.
Por ejemplo, el sitio web A y el sitio web B son servicios afiliados de la misma empresa. Ahora se requiere que mientras el usuario inicie sesión en uno de los sitios web, inicie sesión automáticamente cuando visite otro sitio web, ¿cómo se puede lograr esto?
Una solución es la persistencia de los datos de la sesión, escritos en una base de datos u otra capa de persistencia. Después de recibir la solicitud, varios servicios solicitan datos de la capa de persistencia. La ventaja de este esquema es que la estructura es clara y la desventaja es que la cantidad de ingeniería es relativamente grande. Además, si la capa de persistencia se bloquea, será un único punto de falla.
Otra solución es que el servidor no guarda ningún dato de la sesión, todos los datos se guardan en el cliente y cada solicitud se envía de regreso al servidor. JWT es un representante de este tipo de esquema.
2. El principio de JWT
El principio de JWT es que después de autenticar el servidor, se genera un objeto JSON y se envía de vuelta al usuario, como se muestra a continuación.
{ "姓名": "张三", "角色": "管理员", "到期时间": "2018年7月1日0点0分" }
En el futuro, cuando el usuario se comunique con el servidor, este objeto JSON deberá devolverse. El servidor confía completamente en este objeto para identificar al usuario. Para evitar que los usuarios manipulen los datos, el servidor agregará una firma al generar este objeto (consulte los detalles a continuación).
El servidor no guarda ningún dato de la sesión, es decir, el servidor se vuelve sin estado, lo que facilita su expansión.
3. La estructura de datos de JWT
El JWT real se parece al siguiente.
Es una cuerda larga .separada en tres partes por puntos ( ). Tenga en cuenta que no hay salto de línea dentro del JWT. Aquí está escrito en varias líneas solo para mostrarlo.
Las tres partes de un JWT son las siguientes, en orden.
- Encabezamiento
- Carga útil
- Firma
Escrito en una línea, se parece a lo siguiente.
Header.Payload.Signature
Estas tres partes se describen a su vez a continuación.
3.1 Encabezado
La parte del encabezado es un objeto JSON que describe los metadatos del JWT, generalmente de la siguiente manera.
{ "alg": "HS256", "typ": "JWT" }
En el código anterior, algel atributo indica el algoritmo de firma (algoritmo), el valor predeterminado es HMAC SHA256 (escrito como HS256); el typatributo indica el tipo de token (token) y el token JWT se escribe uniformemente como JWT.
Finalmente, use el algoritmo Base64URL (ver más abajo) para convertir el objeto JSON anterior en una cadena.
3.2 Carga útil
La parte de carga útil también es un objeto JSON, que se utiliza para almacenar los datos reales que deben pasarse. JWT especifica 7 campos oficiales para la selección.
- iss (emisor): emisor
- exp (tiempo de vencimiento): tiempo de vencimiento
- sub (sujeto): sujeto
- aud (audiencia): audiencia
- nbf (no antes): tiempo efectivo
- iat (Emitido en): Hora de emisión
- jti (ID JWT): número
Además de los campos oficiales, también puedes definir campos privados en esta sección, el siguiente es un ejemplo.
{ "sub": "1234567890", "name": "John Doe", "admin": true }
Tenga en cuenta que JWT no está cifrado de forma predeterminada y cualquiera puede leerlo, así que no incluya información secreta en esta sección.
Este objeto JSON también debe convertirse en una cadena utilizando el algoritmo Base64URL.
3.3 Firma
La parte Firma es la firma de las dos primeras partes para evitar la manipulación de datos.
Primero, debe especificar una clave (secreta). Esta clave sólo la conoce el servidor y no puede revelarse al usuario. Luego, utilice el algoritmo de firma especificado en el encabezado (el valor predeterminado es HMAC SHA256) y genere una firma de acuerdo con la siguiente fórmula.
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
Después de calcular la firma, combine las tres partes de Encabezado, Carga útil y Firma en una cadena, separe cada parte con un "punto" ( .) y luego devuélvala al usuario.
3.4 Base64URL
Como se mencionó anteriormente, el algoritmo para la serialización del encabezado y la carga útil es Base64URL. Este algoritmo es básicamente similar al algoritmo Base64, pero existen algunas diferencias menores.
JWT se utiliza como token, que en algunas ocasiones puede colocarse en la URL (como api.example.com/?token=xxx). Base64 tiene tres caracteres y +, que tienen significados especiales en la URL, por lo que deben reemplazarse: omitido, reemplazado por , reemplazado por . Este es el algoritmo Base64URL./==+-/_
4. Cómo utilizar JWT
El cliente recibe el JWT devuelto por el servidor, que puede almacenarse en Cookie o localStorage.
Después de eso, cada vez que el cliente se comunique con el servidor, debe traer este JWT. Puede colocarlo en la cookie y enviarlo automáticamente, pero esto no puede cruzar dominios, por lo que es mejor colocarlo en el Authorizationcampo de información del encabezado de la solicitud HTTP.
Authorization: Bearer <token>
Otro enfoque es que al cruzar dominios, JWT se coloca en el cuerpo de datos de la solicitud POST.
Cinco, varias características de JWT
(1) JWT no está cifrado de forma predeterminada, pero también se puede cifrar. Una vez generado el token original, se puede volver a cifrar con la clave.
(2) Si JWT no está cifrado, los datos secretos no se pueden escribir en JWT.
(3) JWT se puede utilizar no solo para autenticación, sino también para intercambiar información. El uso eficaz de JWT puede reducir la cantidad de veces que el servidor consulta la base de datos.
(4) La mayor desventaja de JWT es que, dado que el servidor no guarda el estado de la sesión, es imposible revocar un token o cambiar el permiso del token durante su uso. Es decir, una vez que se emite un JWT, seguirá siendo válido hasta que caduque, a menos que el servidor implemente lógica adicional.
(5) El propio JWT contiene información de autenticación; una vez filtrada, cualquiera puede obtener todos los permisos del token. Para reducir la apropiación indebida, el período de validez del JWT debería ser relativamente corto. Para algunos permisos más importantes, el usuario debe autenticarse nuevamente al usarlo.
(6) Para reducir la apropiación indebida, JWT no debe transmitirse en texto plano mediante el protocolo HTTP, sino mediante el protocolo HTTPS.