[Reproducción] ¿Cuál es JWT - JSON WEB TOKEN

¿Cuál es JWT - JSON WEB TOKEN

https: // www.jianshu.com/p/576dbf44b2ae

 

¿Cuál es el JWT

Web JSON Token (JWT), es una declaración con el fin de pasar entre el entorno de ejecución de aplicaciones de red basado en estándares abiertos JSON ( (RFC 7519 ). El testigo está diseñado para ser compacto y seguro, especialmente para sitios individuales distribuidos Sign-On (SSO) declaraciones escenario .JWT normalmente se utilizan para suministrar y proveedores de servicios de transferencia entre la identidad del usuario se autentica la información de identidad con el fin de obtener recursos del servidor, también se puede añadir alguna otra lógica de negocio adicional que debe ser información de los estados, el token se puede utilizar directamente para la autenticación se puede cifrar.

origen

Hablando de JWT, deberíamos hablar de la diferencia entre la autenticación y la certificación de la sesión tradicional basada en token.

autenticación de sesión tradicional

Sabemos protocolo, http sí es un protocolo sin estado, y esto significa que si el usuario proporciona un nombre de usuario y contraseña a nuestra solicitud de autenticación de usuario, a continuación, la siguiente petición de tiempo, el usuario debe volver a realizar la autenticación del usuario antes OK, ya que, de acuerdo con el protocolo http, no podemos saber qué petición del usuario se envía, por lo que con el fin de hacer que nuestra aplicación puede identificar qué petición del usuario se emite, la información que podemos almacenar una copia del inicio de sesión de usuario del servidor, esta información de inicio de sesión se le pasará al navegador en respuesta, diciendo a guardarlo como una galleta, para que la próxima vez que la aplicación se envía a nuestra solicitud, por lo que nuestra aplicación será capaz de identificar qué peticiones de los usuarios de, y esta es la autenticación tradicional basada en sesión.

Pero esta autenticación basada en sesión para que la aplicación en sí es difícil de ser ampliado, con el aumento de los usuarios de los diferentes clientes, independiente del servidor no es capaz de llevar a más usuarios, pero esta vez la aplicación de autenticación de sesión basado en problemas será expuesto.

problemas de autenticación basados ​​en la sesión revelaron

Sesión: Cada autenticación de usuario después de nuestra solicitud, nuestra aplicación en el servidor debe hacer un registro, para facilitar la identificación de la próxima petición del usuario, la sesión general se almacenan en la memoria, y como el usuario autenticado aumento en el costo del servidor se incrementará significativamente.

Escalabilidad: Después de la autenticación del usuario, haciendo el registro de autenticación del servidor, si los registros autenticados se almacenan en la memoria, entonces significa que el usuario solicita la siguiente petición debe ser también en este servidor, con el fin de obtener la autorización de los recursos, por lo en una aplicación distribuida, la correspondiente limita la capacidad del equilibrador de carga. Esto también significa que limita la escalabilidad de las aplicaciones.

CSRF: Debido a que se basa en una cookie para identificar al usuario, si se intercepta la cookie, el usuario podría ser vulnerable a ataques de cross-site solicitud falsificación.

El mecanismo de autenticación basada en token

Al igual que en el protocolo HTTP no tiene mecanismo de autenticación basada en token, que no requiere el servidor para retener la información de información de autenticación o sesión del usuario. Esto significa que las aplicaciones basadas en el mecanismo de autenticación de señales no necesita considerar qué servidor el usuario se registra en, lo que facilitó la aplicación de la extensión.

El proceso es el siguiente:

• Usuario de usuario y contraseña a la petición del servidor
• Servidor para verificar la información del usuario
• El servidor envía al usuario mediante la verificación de un contador
• Cliente de memoria token y cada solicitud se incluye en este valor simbólico
• El token de autenticación del servidor, y devuelve los datos

Este token se debe pasar con cada solicitud al servidor, se debe tener en una solicitud de antemano, además, el servidor de apoyo a la CORS(跨来源资源共享)estrategia, por lo general lo hacen en el lado del servidor Access-Control-Allow-Origin: *.

Así que ahora estamos volviendo al tema de JWT.

mirada como JWT?

JWT se compone de tres piezas de información, utilice estos tres trozos de texto de información .con enlaces constituyen cadena Jwt. De esta manera:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

constitución de JWT

La primera parte se llama la cabeza (cabecera), la segunda parte que llamamos la carga (carga útil, similar a los objetos transportados en el avión), y la tercera parte es la visa (firma).

encabezamiento

JWT cabeza lleva dos tipos de información:

• Declarado tipo, aquí está jwt
• Aserción del algoritmo de cifrado se utiliza generalmente directamente HMAC SHA256

cabeza completa como esta en JSON:

{
  'typ': 'JWT',
  'alg': 'HS256'
}

A continuación, la cabeza base64-encriptación (el cifrado puede ser descifrado simétrico), constituye la primera parte.

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

Carga útil

Cargar el almacenamiento local es información válida. El nombre se refiere específicamente a tales mercancías transportadas en la aeronave, estos información eficaz consta de tres partes

• declaración de registro estándar
• Declaración pública
• declaración privada

declaración de registro estándar (recomendado, pero no es obligatorio para el uso):

• ISS JWT emisor
• sub JWT para el usuario
• aud: el lado de recepción jwt
• Exp: tiempo de expiración JWT, la fecha de caducidad debe ser mayor que la cuestión del tiempo
• MNB: ¿A qué hora se define antes de la JWT no están disponibles.
• IAT JWT la cuestión del tiempo
• ITC: JWT identidad única, se utiliza principalmente como una muestra de una sola vez, con el fin de evitar un ataque de repetición.

Declaración pública:
declaraciones públicas pueden añadir cualquier información, información general sobre el usuario para añadir la información necesaria u otras necesidades del negocio, pero no se recomienda para obtener información sensible a añadir, ya que la parte del cliente puede descifrar.

declaración privada:
declaración privada es una declaración de los proveedores y consumidores como definición común, generalmente no se recomienda para almacenar información sensible, debido base 64 se descifran simétrica, lo que significa que parte de la información se pueden clasificar como texto sin formato.

Definir una carga útil:

{
  "sub": "1234567890", "name": "John Doe", "admin": true } 

Base64 entonces ser encriptado para obtener la segunda porción de Jwt.

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

firma

La tercera parte es una información de visas JWT, esta información visado consta de tres partes:

• cabecera (después de la base64)
• carga útil (después de la base64)
• secreto

Y después de base 64 después de que las necesidades de la pieza de cabecera para cifrar la carga útil cifrada usando base64 .composición concatenación de cadenas, y luego por la cabecera de cifrado sal declarada en secretel cifrado de combinación, y la tercera parte constituye el JWT.

// javascript
var encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload); var signature = HMACSHA256(encodedString, 'secret'); // TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ 

Estas tres piezas con .una cadena completa conectada, constituye el final de JWT:

  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Nota: secreta se almacena en el servidor, el problema generado JWT también en el lado del servidor, secreto se utiliza para autenticar la emisión y jwt de JWT, por lo que es clave privada del servidor, en cualquier escenario no debe ser revelada a seguir. Una vez que el cliente ha aprendido el secreto, que significa que el cliente puede ser auto-firmado por JWT.

Cómo aplicar

Se añade generalmente con antelación en la solicitud Authorizationy añada el Bearersello:

fetch('api/user/1', {
  headers: {
    'Authorization': 'Bearer ' + token
  }
})

Los servidores verifica la clave, si se verifica que devolverán el recurso correspondiente. Todo el proceso es así:

 

jwt-diagrama

resumen

ventaja

• Debido a la versatilidad de JSON, por lo que puede ser JWT apoyo entre lenguajes, como Java, JavaScript, NodeJS, PHP y muchos otros idiomas se pueden utilizar.
• Debido a la sección de carga útil, lo que puede almacenar alguna otra lógica de negocio necesaria para JWT información no sensible en sí mismo.
• Facilidad de transporte, la configuración es JWT pequeñas bytes muy simples, ocupados, lo que es muy fácil de transportar.
• No requiere el servidor para guardar información de la sesión, por lo que es fácil de extender la aplicación

relacionados con la seguridad

• No debemos almacenar información confidencial en la sección de carga útil JWT, ya que es parte del cliente puede descifrar parte.
• Proteger la clave privada secreta que es muy importante.
• Si puede, por favor utilice el protocolo https