El contexto de organización de este artículo es el siguiente
Cookie 和 Sesión
El protocolo HTTP es un tipo 无状态协议, es decir, cada vez que el servidor recibe la solicitud de un cliente, es una solicitud nueva y el servidor no conoce el registro histórico de solicitudes del cliente; el propósito principal de Sesión y Cookie es compensar la naturaleza sin estado de HTTP.
Que es Session
El cliente solicita el servidor y el servidor abrirá un bloque para esta solicitud 内存空间Este objeto es el objeto Sesión y la estructura de almacenamiento es ConcurrentHashMap. La sesión compensa la naturaleza sin estado de HTTP. El servidor puede usar Session para almacenar algunos registros de operación del cliente durante la misma sesión.
Cómo determinar si la sesión es la misma sesión
Cuando el servidor recibe la solicitud por primera vez, abre un espacio de sesión (crea un objeto de sesión) y genera un sessionId al mismo tiempo, y envía una respuesta solicitando la configuración de cookies al cliente a través de Set-Cookie: JSESSIONID = Comando XXXXXXX en el encabezado de respuesta; después de que el cliente recibe la respuesta, establece una cookie con JSESSIONID = XXXXXXX en el cliente local. El tiempo de vencimiento de la cookie es el final de la sesión del navegador.
Luego, cada vez que el cliente envía una solicitud al mismo sitio web, el encabezado de la solicitud llevará la información de la cookie (incluido el sessionId). Luego, el servidor lee la información de la cookie en el encabezado de la solicitud y obtiene el valor llamado JSESSIONID para obtener el valor de JSESSIONID. El sessionId solicitado.
Desventajas de Session
El mecanismo de sesión tiene una deficiencia. Por ejemplo, el servidor A almacena la sesión, es decir, después del equilibrio de carga, si el volumen de acceso de A aumenta drásticamente durante un período de tiempo, se reenviará a B para acceder, pero el servidor B no almacena el de A Session, lo que provocará la falla de Session.
Que son las cookies
El protocolo HTTP cookie comprende Web Cookie y 浏览器 Cookie, el servidor lo envía al navegador web de pequeños bloques de datos. La cookie enviada por el servidor al navegador será almacenada por el navegador y enviada al servidor junto con la siguiente solicitud. Por lo general, se usa para determinar si dos solicitudes provienen del mismo navegador, por ejemplo, el usuario permanece conectado.
El mecanismo de cookies HTTP es un complemento y una mejora del protocolo HTTP sin estado.
Las cookies se utilizan principalmente para los siguientes tres propósitos
-
会话管理
Inicio de sesión, carrito de compras, puntuación del juego u otras cosas que el servidor debe recordar
-
个性化
Preferencias de usuario, temas u otras configuraciones
-
追踪
Registrar y analizar el comportamiento del usuario
Las cookies se utilizaron una vez para el almacenamiento general del cliente. Aunque esto es legal porque son la única forma de almacenar datos en el cliente, ahora se recomienda utilizar API de almacenamiento modernas. Las cookies se envían con cada solicitud, por lo que pueden reducir el rendimiento (especialmente para las conexiones de datos móviles).
Crear cookie
Al recibir una solicitud HTTP de un cliente, el servidor puede enviar un Set-Cookie encabezado con una respuesta . La cookie generalmente es almacenada por el navegador, y luego la cookie y el encabezado HTTP se combinan para enviar una solicitud al servidor.
Encabezado Set-Cookie y Cookie
Set-Cookie El encabezado de respuesta HTTP envía la cookie desde el servidor al agente de usuario. El siguiente es un ejemplo de envío de cookies.
Este encabezado le dice al cliente que almacene cookies
Ahora, con cada nueva solicitud al servidor, el navegador utilizará el encabezado Cookie para enviar todas las cookies almacenadas previamente al servidor.
Hay dos tipos de cookies, una son cookies de sesión y la otra son cookies persistentes.Si la cookie no contiene una fecha de vencimiento, se considerará como una cookie de sesión. La cookie de sesión se almacena en la memoria y nunca se escribirá en el disco. Cuando se cierra el navegador, la cookie se perderá permanentemente a partir de entonces. Si la cookie contiene 有效期 , se tratará como una cookie persistente. En la fecha de vencimiento especificada, la cookie se eliminará del disco.
Hay otro Cookie的 Secure 和 HttpOnly 标记, vamos a introducir uno por uno a continuación.
Cookies de sesión
El ejemplo anterior crea una cookie de sesión. La cookie de sesión tiene una función. La cookie se eliminará cuando se cierre el cliente porque no tiene designación Expiresni Max-Age instrucción.
Sin embargo, los navegadores web pueden utilizar la restauración de sesión, lo que hace que la mayoría de las cookies de sesión sean permanentes, como si el navegador nunca se hubiera cerrado.
Cookies persistentes
Las cookies persistentes no caducarán cuando se cierre el cliente, pero caducarán dentro 特定日期（Expires）o 特定时间长度（Max-Age）fuera. P.ej
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
Etiquetas de Cookie's Secure y HttpOnly
La cookie segura debe enviarse al servidor de forma cifrada a través del protocolo HTTPS. Incluso si es segura, la información confidencial no debe almacenarse en cookies porque son intrínsecamente inseguras y esta bandera no brinda una protección real.
El papel de HttpOnly
-
La falta del atributo HttpOnly en la cookie de sesión hará que un atacante obtenga la información de la cookie del usuario a través de programas (script JS, Applet, etc.), lo que provocará que se filtre la información de la cookie del usuario y aumente la amenaza del atacante de realizar scripts entre sitios ataques.
-
HttpOnly es la extensión de Microsoft para Cookie. Este valor especifica si se puede acceder a la Cookie a través de scripts del lado del cliente.
-
Si el atributo HttpOnly no se establece en verdadero en la cookie, la cookie puede ser robada. Las cookies robadas pueden contener información confidencial que identifica a los usuarios del sitio, como ID de sesión de ASP.NET o tickets de autenticación de formularios. Los atacantes pueden reproducir las cookies robadas para hacerse pasar por usuarios u obtener información confidencial, realizar ataques de secuencias de comandos entre sitios, etc.
Alcance de las cookies
Domain Y el Path logotipo define el alcance de la cookie: a qué URL se debe enviar la cookie.
Domain El identificador especifica qué hosts pueden aceptar cookies. Si no se especifica, se utilizará de forma predeterminada en el host actual ( sin incluir los subdominios ). Si se especifica Domain, generalmente contiene el nombre del subdominio.
Por ejemplo, si se configura Domain=mozilla.org, la cookie también se incluye en el subdominio (p developer.mozilla.org. Ej .).
Por ejemplo, establezca Path=/docs, las siguientes direcciones coincidirán todas:
-
/docs -
/docs/Web/ -
/docs/Web/HTTP
Comparación de JSON Web Token y cookies de sesión
JSON Web Token ，简称 JWTAmbos Sessionpueden proporcionar autenticación de usuario para el sitio web, pero no son lo mismo.
El siguiente es un estudio de la diferencia entre JWT y Session
Similitudes entre JWT y cookies de sesión
Antes de hablar sobre JWT y las cookies de sesión, es necesario comprender sus similitudes.
Se pueden usar para autenticar a los usuarios, y también se pueden usar para autenticar a los usuarios cuando hacen clic para ingresar a una página diferente y después de iniciar sesión en un sitio web o aplicación.
Si no tiene estos dos, es posible que deba iniciar sesión en cada cambio de página. Porque HTTP es un protocolo sin estado. Esto significa que cuando visita una página web y luego hace clic en otra página del mismo sitio, el servidor 内存中no recordará sus acciones anteriores.
Por lo tanto, si inicia sesión y visita otra página a la que tiene permiso para acceder, ya que HTTP no registra la información que acaba de iniciar sesión, volverá a iniciar sesión.
Las cookies de sesión y JWT se utilizan para manejar el cambio entre diferentes páginas y guardar la información de inicio de sesión del usuario .
En otras palabras, estas dos tecnologías se utilizan para guardar su estado de inicio de sesión, lo que le permite navegar por cualquier sitio web protegido por contraseña. Este problema se resuelve autenticando los datos del usuario cada vez que se realiza una nueva solicitud.
Entonces, ¿cuáles son las similitudes entre JWT y las cookies de sesión? Es decir, pueden ayudarlo a registrar y verificar un mecanismo de su estado de inicio de sesión entre el envío de diferentes solicitudes.
¿Qué son las cookies de sesión?
Las cookies de sesión también se denominan 会话 Cookies, en las cookies de sesión, el estado de inicio de sesión del usuario se guardará en 服务器el 内存medio. Cuando el usuario inicia sesión, el servidor crea la sesión de forma segura.
En cada solicitud, el servidor leerá el SessionId de la cookie de sesión. Si los datos en el servidor son los mismos que los del SessionId leído, el servidor enviará una respuesta al navegador para permitir que el usuario inicie sesión.
¿Qué son los tokens web Json?
La abreviatura de Json Web Token es JWT, que normalmente se puede llamar Json 令牌. Se RFC 7519 define 安全的como Json 对象una forma de transmisión de información . La información almacenada en el JWT se transmite 数字签名, por lo que se puede confiar y comprender. Puede utilizar el algoritmo HMAC o utilizar la clave pública / privada RSA / ECDSA para firmar el JWT.
El uso de JWT se utiliza principalmente para los dos puntos siguientes
-
认证(Authorization): Este es el caso más común de uso de JWT. Una vez que el usuario inicia sesión, cada solicitud posterior contendrá el JWT, lo que le permitirá acceder a las rutas, servicios y recursos permitidos por el token.单点登录Es una característica de JWT que se usa ampliamente en la actualidad debido a su pequeña sobrecarga. -
信息交换(Information Exchange): JWT es una forma de transmitir información de forma segura. El JWT se firma y se autentica mediante el uso de la clave pública / clave privada. Además, dado que la firma se utilizaheadypayloadcalcula, también puede verificar si el contenido ha sido manipulado.
Formato JWT
A continuación, discutiremos cuál es la composición y el formato de JWT.
JWT se compone principalmente de tres partes, cada parte . se divide en
-
Header -
Payload -
Signature
Por lo tanto, una composición JWT muy simple sería la siguiente
Luego discutimos las diferentes partes por separado.
Encabezamiento
El encabezado es el encabezado de JWT, generalmente consta de dos partes: 令牌的类型(即 JWT)y usado 签名算法, como HMAC SHA256 o RSA.
P.ej
{
"alg": "HS256",
"typ": "JWT"
}
Después de especificar el tipo y el algoritmo de firma, el bloque Json se Base64Url codifica para formar la primera parte del JWT.
Carga útil
La segunda parte del token es Payloadque Payload contiene una declaración. Una declaración es una declaración sobre una entidad (generalmente un usuario) y otros datos. Hay tres tipos de declaraciones: registradas, públicas y privadas .
-
registered 声明: Contiene un conjunto de declaraciones predefinidas recomendadas, que incluyen principalmente
-
public 声明: Declaración pública, puede agregar cualquier información, generalmente agregar información relacionada con el usuario u otra información necesaria requerida por la empresa, pero no se recomienda agregar información confidencial, porque esta parte se puede descifrar en el cliente. -
private 声明: Las declaraciones personalizadas, destinadas a compartir información entre las partes que acuerdan utilizarlas, no son declaraciones de registro ni declaraciones públicas.
P.ej
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
Luego, el bloque Json de carga útil se Base64Url codificará para formar la segunda parte del JWT.
firma
La tercera parte de JWT es una información de visa, esta información de visa consta de tres partes
-
encabezado (después de base64)
-
payload (después de base64)
-
secreto
Por ejemplo, necesitamos el algoritmo HMAC SHA256 para firmar
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
La firma se utiliza para verificar que el mensaje no ha cambiado en el proceso, y para los tokens firmados con una clave privada, también puede verificar la verdadera identidad del remitente del JWT.
Juntar
Ahora juntamos las tres partes de cadena de URL Base64 separadas por puntos, esta cadena puede pasar fácilmente estas cadenas en entornos HTML y HTTP.
El siguiente es un ejemplo completo de JWT, que codifica el encabezado y la carga útil, y luego usa la firma para firmar
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
Si desea probar y escribir usted mismo, puede visitar el sitio web oficial de JWT https://jwt.io/#debugger-io
La diferencia entre JWT y cookies de sesión
Tanto JWT como las cookies de sesión proporcionan una autenticación segura del usuario, pero son diferentes en los siguientes puntos
Firma criptográfica
JWT tiene una firma criptográfica, pero las cookies de sesión no.
JSON no tiene estado
JWT Sí 无状态, porque la declaración se almacena en la 客户端memoria del servidor, no en ella.
Se puede 本地realizar la autenticación , en lugar de solicitar que el servidor tenga una base de datos o similar en su posición. Esto significa que el usuario puede autenticarse varias veces sin tener que comunicarse con la base de datos del sitio o la aplicación, y sin consumir muchos recursos en el proceso.
Escalabilidad
Las cookies de sesión se almacenan en la memoria del servidor, lo que significa que si el sitio web o la aplicación es grande, consumirá muchos recursos. Dado que los JWT no tienen estado, en muchos casos pueden ahorrar recursos del servidor. Por lo tanto, JWT es más fuerte que las cookies de sesión 可扩展性.
JWT admite la autenticación entre dominios
Las cookies de sesión solo pueden usarse 单个节点的域o ser 子域válidas en él . Si intentan acceder a través del tercer nodo, serán baneados. Esto es un problema si desea que su sitio web establezca una conexión segura con otros sitios.
El uso de JWT puede resolver este problema, el uso de JWT puede pasar 多个节点la autenticación de usuario, que es lo que solemos decir 跨域认证.
Selección de JWT y cookies de sesión
Discutimos la diferencia entre JWT y Cookies anteriormente, creo que también tendrá una comprensión más profunda de la selección, en términos generales
Para sitios web pequeños y medianos que solo necesitan iniciar sesión como usuarios y acceder a cierta información almacenada en la base de datos del sitio, las cookies de sesión suelen ser suficientes.
Si tiene sitios de nivel empresarial, aplicaciones o sitios cercanos, y necesita manejar una gran cantidad de solicitudes, especialmente de terceros o muchos terceros (incluidas las API en diferentes dominios), JWT es obviamente más adecuado.
posdata
Hice esta pregunta durante la entrevista hace dos días, así que escribí un artículo para resumir, y también hice una pregunta de entrevista, deshabilitando Cookies, ¿cómo usar Session ? Lo revisé en Baidu y descubrí que esta es una pregunta de entrevista de PHP, em .....
Pero todavía elijo entender cómo usar la sesión después de deshabilitar las cookies
-
Si las cookies están deshabilitadas, el servidor seguirá enviando el sessionId al navegador en forma de cookie, pero el navegador ya no guardará esta cookie (es decir, sessionId).
-
Si desea continuar usando la sesión, debe usar
URL 重写el método para lograrlo, puede consultar https://www.cnblogs.com/Renyi-Fan/p/11012086.html
Referencias relacionadas:
https://www.cnblogs.com/Renyi-Fan/p/11012086.html
https://blog.csdn.net/qq_28296925/article/details/80921585
https://www.cnblogs.com/-ROCKS/p/6108556.html
https://www.allaboutcookies.org/manage-cookies/
https://www.jianshu.com/p/4a124a10fcaf
https://tools.ietf.org/html/rfc7519
https://jwt.io/introduction/
https://wp-rocket.me/blog/browser-cache-vs-cookies-difference/
https://wp-rocket.me/blog/difference-json-web-tokens-vs-session-cookies/