¿Qué es un token? En comparación con las sesiones y las cookies, ¿cuáles son las diferencias en los escenarios de uso?
En el campo del desarrollo web, creo que todo el mundo está familiarizado con Cookie y Session. Tanto Cookie como Session son soluciones tecnológicas de persistencia de sesión. Con el desarrollo de la tecnología, el mecanismo Token aparece frente a nosotros, pero muchos desarrolladores no pueden distinguir las diferencias y los escenarios de uso entre Token, Cookie y Sesión. El propósito de la cookie y la sesión
Debes saber que nuestro acceso al sitio web se completa a través del protocolo HTTP o el protocolo HTTPS. El protocolo HTTP en sí es un protocolo sin estado (es decir, el servidor no puede saber qué solicitudes). se originan en el mismo servidor). El nivel empresarial implicará la interacción entre el cliente y el servidor (los datos se pueden compartir entre varias páginas en el mismo sitio web). En este momento, el servidor debe mantener el estado de la sesión para que se pueda autenticar la identidad del usuario.
Debido a la naturaleza sin estado de HTTP, si desea mantener la sesión entre el cliente y el servidor, se necesitan otros mecanismos para lograrlo, por lo que surgieron Cookie y Session.
Por lo general, la sesión y la cookie se utilizan juntas. ¿Qué es Token?
Existe un problema con los mecanismos de sesión y cookies mencionados anteriormente para mantener las sesiones: el navegador del cliente solo necesita guardar su propio ID de sesión, pero el servidor necesita guardar la información de sesión de todos los usuarios. ¡Esto es costoso para el servidor y no aprovecha la expansión del servidor (por ejemplo, cuando el servidor está en clúster, cómo sincronizar el almacenamiento de la sesión es un problema)!
Entonces algunas personas pensaron: ¿no se resolvería este problema si el cliente conservara la información de la sesión y no pudiera falsificarla? Luego está el mecanismo Token.
El token se conoce comúnmente como "token" y su composición es: Proceso de autenticación bajo el mecanismo Token
El mecanismo Token es en realidad muy similar al mecanismo Cookie, con los siguientes principales procesos:
1. El usuario inicia sesión para la autenticación de identidad. Después de una autenticación exitosa, el servidor genera un Token y lo devuelve al cliente
2. Después de que el cliente recibe el Token; , se guarda en el cliente (se puede guardar en Cookie, LocalStorage, SessionStorage);
3. Cuando el cliente solicita al servidor nuevamente, el token se coloca en los encabezados como encabezado de solicitud
4. El servidor recibe el Token en el encabezado de la solicitud. Los parámetros del usuario se firman nuevamente de acuerdo con las reglas establecidas. Si las dos firmas son consistentes, se considera exitosa. De lo contrario, la solicitud falla debido a la manipulación de datos. .
(Imagen de ejemplo para generar firma)
(Imagen de ejemplo para verificar firma) La diferencia entre Token y Sesión de Cookie
Cookie en realidad sirve como La función del token es que tiene "estado" mientras que el Token no tiene estado y es más propicio para la implementación distribuida.
Sesión y cookie
Antes de hablar de Token, hablemos brevemente de qué son sesión y cookie.
Token
Pero hay un problema aquí. El servidor necesita guardar la información de la sesión de todos los usuarios, lo que será muy costoso si está en una arquitectura distribuida, sesión *. * debe considerarse. * Los problemas de uso compartido requieren diseño y desarrollo adicionales, como guardar la información de la sesión en Redis para * compartirla, por lo que algunas personas consideran si el cliente puede guardar esta información; en cualquier lugar y garantizar su seguridad, por eso existe Token.
El token es una cadena de caracteres generada por el servidor, que puede considerarse como un token utilizado por el cliente para realizar solicitudes.
Proceso de autenticación basado en tokens
El proceso general es el siguiente:
Resumen ¡Espero que mi respuesta pueda ayudarte! Continuaré compartiendo mis conocimientos sobre el desarrollo de Java, el diseño de arquitectura, el desarrollo profesional de programadores, etc., y espero llamar su atención.
Token, como su nombre lo indica, es un token, un certificado y una clave. Sólo con esta llave podrás abrir la puerta. Los tokens generalmente los genera el servidor. Por ejemplo, en un sistema web, cuando un usuario inicia sesión, después de que el servidor verifica el nombre de usuario y la contraseña, se generará un token, junto con un refresco y un tiempo de vencimiento. Luego, el refresco y el token se devuelven al cliente. El cliente guardará el token. Todas las solicitudes posteriores llevarán este token. El servidor determinará si el token actual existe y ha caducado. Si el token no existe o caduca, la solicitud será rechazada. ¿Qué hacer si el token caduca? Utilice refrescoToken para actualizar la hora. Por supuesto, puede haber otras opciones aquí. Por ejemplo, solo se genera un token y el tiempo de vencimiento se actualiza cada vez que se realiza una solicitud. Si el tiempo de vencimiento no se actualiza durante un período prolongado, el token caducará.
La sesión es una respuesta, que es una operación en el lado del servidor. Cuando visita un sitio web por primera vez, el servidor generará una sesión y tendrá un ID de sesión correspondiente. Esta sesión se almacena en la memoria. Puede escribir información en esta sesión, como la información del usuario que ha iniciado sesión actualmente. El ID de sesión se devolverá al cliente y el cliente generalmente utiliza cookies para guardarlo. Por supuesto, no es necesario escribir esta cookie manualmente. Tomemos el contenedor Tomcat como ejemplo. Cuando el backend llama al método getSession del objeto HttpServletRequest, Tomcat generará un jsessonid (el nombre de Tomcat sessionid) internamente. Este jsessonid se devolverá al cliente con esta solicitud. Información del encabezado de respuesta
Este jessionid se escribirá en la cookie. Luego, el jessionid se pasará al servidor a través de la cookie.
Aquí seremos muy claros, los datos de la sesión se almacenan en la memoria. Entonces surge el problema, si nuestro servicio se implementa de manera distribuida y tiene varias máquinas, tal vez cuando iniciamos sesión por primera vez, almacenamos la información del usuario en la sesión, pero las solicitudes posteriores van a la máquina B. Luego, la máquina B. no se puede obtener la sesión del usuario. Además, la sesión se almacena en la memoria. Si se reinicia el servidor, la sesión se perderá. Ahora existen algunas tecnologías, como compartir sesión, iphash, persistencia de sesión, etc., que también pueden resolver los problemas anteriores.
Las cookies son una política del navegador.
Como se mencionó anteriormente, el ID de sesión se almacena en la cookie. Sabemos que el protocolo http no tiene estado y se utilizan cookies para resolver este problema. Las cookies se pueden utilizar para guardar cierta información del usuario devuelta por el servidor, como el token y el ID de sesión mencionados anteriormente. Cada solicitud llevará estas cookies. Una vez que el servidor obtiene la información de la cookie del encabezado de la solicitud, puede identificar el origen de esta solicitud. De esta manera, HTTP pasará a tener estado.
A continuación se muestran algunas precauciones sobre las cookies.
1. Las cookies se almacenan en el lado del cliente, por lo que no son seguras. Se puede borrar manualmente
2. La cookie tiene una configuración de tiempo de vencimiento. Si no se establece el tiempo de vencimiento, significa que esta cookie es el tiempo de sesión del navegador actual. Si el navegador está cerrado, la cookie existirá. Si hay una fecha de vencimiento, la cookie se almacenará en el disco duro y cerrar el navegador no afectará a la cookie. La próxima vez que abra el navegador, la cookie seguirá existiendo
3. Las cookies tienen un límite de tamaño de 4 KB.
Hay muchas respuestas a esta pregunta en Internet. Creo que las he leído todas, pero probablemente no las entiendo. Así que no lo copiaré en línea. Usaré mis propias palabras y trataré de ser lo más conciso y centrado posible.
La cookie y la sesión son en realidad el mismo proceso de autenticación y se complementan entre sí. La sesión se guarda en el servidor y la cookie se guarda en el cliente. El enfoque más común es que la cookie del cliente solo guarde un ID de sesión. Este ID de sesión es un número aleatorio irregular que el servidor genera aleatoriamente después de que el cliente inicia sesión. A partir de ahora, cada vez que el cliente visite el sitio web deberá traer esta cookie compuesta por sessionID. Cuando el servidor recibe la solicitud, primero obtiene el ID de sesión del cliente y luego consulta al cliente que representa (nombre de usuario, grupo de usuarios, permisos, etc.) de la memoria del servidor.
En comparación con el token, el punto clave aquí es que el servidor debe guardar el ID de sesión y la información del cliente representada por el ID. Estos contenidos se pueden guardar en la memoria o en una base de datos (generalmente una base de datos en memoria).
Con el token, el servidor no necesita guardar ninguna información de inicio de sesión.
El proceso del token es así. Después de que el cliente inicia sesión correctamente, el servidor genera una gran cantidad de información de identidad del cliente, incluido el nombre de usuario, el grupo de usuarios, los permisos que tiene, el tiempo de vencimiento, etc. Además, la información está firmada. Luego, la información de identidad y la firma se pasan al cliente en su conjunto. Este conjunto se llama token. Después de eso, el cliente es responsable de guardar el token y el servidor ya no lo guarda. El cliente deberá traer este token cada vez que visite el sitio web. Una vez que el servidor recibe la solicitud, la divide en información de identidad y firma, y luego verifica la firma. Si la verificación es exitosa, utiliza directamente la información de identidad (nombre de usuario, grupo de usuarios, permisos, etc.).
Se puede ver que, en comparación con el mecanismo de cookie/sesión, en el mecanismo de token, el servidor no necesita guardar la información de identidad del usuario (nombre de usuario, grupo de usuarios, permisos, etc.) en absoluto. . Esto reduce la carga en el servidor.
Pongamos un ejemplo, suponiendo que actualmente hay 10 millones de usuarios conectados y visitando diferentes páginas web. Si se utilizan cookies/sesión, la información de 10 millones de usuarios debe registrarse simultáneamente en la memoria del servidor (o base de datos en memoria). Cada vez que un cliente accede a una página, el servidor debe consultar su información de inicio de sesión desde la memoria. Si se utiliza un token, la información de inicio de sesión del usuario no se registrará en la memoria del servidor. Solo necesita utilizar directamente la información de identidad de inicio de sesión enviada por el cliente después de recibir la solicitud.
Se puede decir que cookie/sesión es el servidor que le dice al cliente quién es el cliente.
El token es quien el cliente dice que soy (el cliente), y yo soy quien soy. Por supuesto, los tokens tienen un mecanismo de firma. Si el cliente falsifica su identidad, la firma fallará. Este algoritmo de firma es muy simple. Consiste en agregar la información de identidad del cliente a un valor salt que solo el servidor conoce (que no se puede filtrar) y luego realizar el algoritmo hash md5 (esto simplemente se simplifica para una fácil comprensión, los detalles reales). son un poco más complicados).
La cookie/sesión es relativamente simple cuando se utiliza un solo servidor y un solo nombre de dominio. De lo contrario, debe considerar cómo guardar o sincronizar la sesión del cliente en varios servidores. Considere también si la información en la memoria se perderá una vez que la computadora falle. Debido a que el servidor no guarda la identidad del usuario, este problema no existe. Ésta es la ventaja del token.
Token Debido a que el servidor no guarda información de identidad del usuario, todo depende de la firma original. Por tanto, existe el riesgo de que lo roben. En otras palabras, una vez robado, el servidor puede quedar indefenso porque sólo reconoce el algoritmo de firma. En cuanto al mecanismo de sesión, el servidor puede expulsar a alguien (eliminarlo de la memoria) en cualquier momento si no está satisfecho con él. Debido a esto, los tokens dependen en gran medida del tiempo de vencimiento. El tiempo de vencimiento no puede ser demasiado largo. El corto tiempo de vencimiento reduce el riesgo de apropiación indebida.
Además de lo anterior, personalmente creo que si el sistema desarrollado es lo suficientemente pequeño, tiendo a utilizar cookies/sesión. Si hay muchos usuarios que inician sesión en el sistema al mismo tiempo, hay muchos servidores de clúster y existe un requisito de inicio de sesión único, se tienden a utilizar tokens. Historia del desarrollo de la World Wide Web
Token, token, objeto que representa el derecho a realizar determinadas operaciones.
Los tokens se utilizan principalmente para la autenticación y se dividen principalmente en las siguientes categorías:
Las cookies son principalmente datos utilizados por los sitios web para almacenar temporalmente en los navegadores, incluidos los datos de la caché del navegador y la configuración del servidor. Ciertos datos se almacenan principalmente en el lado del navegador.
La sesión se utiliza principalmente para guardar datos de la sesión, que generalmente se almacenan en el lado del servidor. Al mismo tiempo, cada par de sesiones utiliza una ID de sesión, y la ID de la sesión se almacena en la cookie del navegador. .
Tradicionalmente, el inicio de sesión y la autenticación se implementan principalmente mediante sesión y cookie. Con la rápida evolución de los sistemas distribuidos, especialmente la aplicación de microservicios, se favorece el mecanismo de acceso autorizado de la cookie token, generalmente después del usuario. inicia sesión, el servidor genera un token de acceso, que el navegador almacena en la cookie. Cada vez que se solicita un recurso, el token se incluye en el encabezado de solicitud para el acceso autorizado por parte del servidor.
El token y la sesión son soluciones para el mantenimiento de sesiones y la autenticación de sitios web.
Dado que son iguales, ¿por qué sigue existiendo un término para token?
Comencemos con los antecedentes de la producción de tokens
1. Las aplicaciones móviles invalidan las sesiones del lado del servidor
2. Las sesiones no se pueden compartir en sistemas distribuidos
Entonces, la sesión no es válido para las dos situaciones anteriores, por lo que existe el término Token. Entonces, ¿qué es un token y cómo se ve?
Primero déjame darte una sensación intuitiva
token: PC-3066014fa0b10792e4a762-23-20170531133947-4f6496
Para decirlo sin rodeos, el token guardado es el información del usuario (no se puede guardar Contraseña y otra información confidencial)
Composición del token:
ID de cliente-USERCODE-USERID-CREATIONDATE-RONDEM[6 dígitos]
USERCODE, RONDEM[6 bits] Después del cifrado MD5, se convierte en el proceso de solicitud del token de cadena anterior
Análisis del proceso de solicitud
1. El frente -el usuario final envía información de inicio de sesión al sistema de autenticación
2. Verificar la información de inicio de sesión del usuario y determinar si el usuario existe
3. Si el usuario existe, generar información del token (identificación del cliente- USERCODE-USERID-CREATIONDATE-RONDEM [6 dígitos]), y se almacena en redis
4. Devuelva el token al front-end y adjúntelo al token de verificación del encabezado
Cliente
Adjunte el token al encabezado
Servidor
Resumen final
No hay ningún problema en usar Session para proyectos generales de arquitectura vertical, pero para proyectos distribuidos o que involucran terminales móviles, considere el uso de tokens.
sesión
La traducción china de sesión es "sesión". Cuando el usuario abre una aplicación web, se genera una sesión con el servidor web. El servidor utiliza la sesión para almacenar temporalmente la información del usuario en el servidor. La sesión se destruirá después de que el usuario abandone el sitio web. Este método de almacenar información del usuario es más seguro que las cookies, pero la sesión tiene un defecto: si el servidor web tiene la carga equilibrada, la sesión se perderá cuando la siguiente solicitud de operación vaya a otro servidor.
Cookie
Cookie son datos almacenados en el terminal local. La cookie es generada por el servidor y enviada al navegador. El navegador guarda la cookie en formato kv en un archivo de texto en un directorio determinado. La cookie se enviará al servidor la próxima vez que se solicite el mismo sitio web. Dado que las cookies se almacenan en el cliente, el navegador ha agregado algunas restricciones para garantizar que las cookies no se utilicen de forma maliciosa y no ocupen demasiado espacio en el disco, por lo que la cantidad de cookies para cada dominio es limitada.
Los componentes de una cookie son: nombre (clave), valor (valor), dominio válido (dominio), ruta (ruta del dominio, generalmente configurada en global: ""), tiempo de vencimiento, indicador de seguridad ( especificado Finalmente, la cookie solo se envía al servidor cuando se utiliza una conexión SSL (https).
El siguiente es un ejemplo simple de js usando cookies:
Se genera una cookie cuando el usuario inicia sesión:
document.cookie = "id=" result.data['id' ] "; ruta=";
document.cookie = "nombre=" resultado.data['nombre'] "; ruta="
document.cookie = "avatar=; " result .data['avatar'] "; path=/";
Cuando utilices cookies, haz el siguiente análisis:
var cookie = document.cookie; var cookieArr = cookie .split( ";"); var user_info = {}; para (var i = 0; i lt; cookieArr.length; i) {
user_info[cookieArr[i].split("=" )[0 ]] = cookieArr[i].split("=")[1]
}
$('#user_name').text(user_info[' nombre; '])
$('#user_avatar').attr("src", user_info[' avatar']); user_info[' id']);
token
Token significa "token", que es una forma de verificar la identidad del usuario. El token más simple consiste en: uid (el único del usuario). identidad), hora (marca de tiempo de la hora actual), signo (firma, las primeras sales del token se comprimen en una cierta longitud de cadena hexadecimal utilizando un algoritmo hash, que puede evitar que terceros malintencionados unan solicitudes de token al servidor ). También puede colocar parámetros sin cambios en el token para evitar múltiples búsquedas en la base de datos
La diferencia entre cookies y sesiones
1. Los datos de las cookies se almacenan en el navegador del cliente y los datos de la sesión Ponlo en el servidor.
2. Las cookies no son muy seguras. Otras pueden analizar la COOKIE almacenada localmente y engañar a la COOKIE.
Se debe utilizar la sesión por razones de seguridad.
3. La sesión se guardará en el servidor durante un periodo de tiempo determinado. Cuando el acceso aumenta, consumirá una mayor parte del rendimiento de su servidor.
Para reducir el rendimiento del servidor, se debe utilizar COOKIE.
4. Los datos guardados por una sola cookie no pueden exceder los 4K. Muchos navegadores limitan un sitio para guardar hasta 20 cookies.
5. Sugerencias personales:
Almacene información importante, como información de inicio de sesión, como SESIÓN
Si es necesario conservar otra información, se puede colocar en COOKIE
La diferencia entre token y sesión
La sesión y el token oauth no son contradictorios. Como token de autenticación de identidad, la seguridad es mejor que la sesión, porque cada solicitud está firmada y puede evitar el monitoreo. y ataques de reproducción. La sesión debe depender de la capa de enlace para garantizar la seguridad de la comunicación.
Como se mencionó anteriormente, si necesita implementar una sesión con estado, aún puede agregar una sesión para guardar algún estado en el lado del servidor.
Las aplicaciones generalmente usan API de descanso para tratar con el servidor. El resto no tiene estado, es decir, la aplicación no necesita usar cookies para guardar sesiones como los navegadores, por lo que es suficiente usar tokens de sesión para marcarse. La lógica del servidor API procesa la sesión/estado. Si su backend no es una API de descanso sin estado, es posible que deba guardar la sesión en la aplicación. Puede incrustar un webkit en la aplicación y usar un navegador oculto para administrar las sesiones de cookies.
La sesión es un tipo. de HTTP El mecanismo de almacenamiento está destinado a proporcionar un mecanismo de persistencia para HTTP sin estado. La llamada autenticación de sesión simplemente almacena información del usuario en la sesión. Debido a la imprevisibilidad del SID, se considera segura por el momento. Este es un medio de autenticación. Y Token, si se refiere a OAuth Token o un mecanismo similar, proporciona autenticación y autorización. La autenticación es para los usuarios y la autorización es para la aplicación. El propósito es otorgar a una aplicación el derecho de acceder a la información de un usuario. El Token aquí es único. No se puede transferir a otras Apps ni a otros usuarios. Pase a Sesión. La sesión solo proporciona una autenticación simple, es decir, tener este SID significa que el usuario tiene todos los derechos. Deben mantenerse estrictamente confidenciales. Estos datos solo deben almacenarse en el sitio y no deben compartirse con otros sitios web ni aplicaciones de terceros. En pocas palabras, si es posible que sea necesario compartir sus datos de usuario con un tercero o permitir que un tercero llame a la interfaz API, utilice Token. Si siempre es solo tu propio sitio web y tu propia aplicación, no importa lo que uses.
El token es un token. Por ejemplo, cuando autoriza (inicie sesión) un programa, es una base para determinar si ha autorizado el software. Una cookie es un archivo txt escrito en el cliente; incluye su información de inicio de sesión, etc., de modo que la próxima vez que inicie sesión en un sitio web, la cookie se llamará automáticamente para iniciar sesión automáticamente. La sesión es similar a la cookie, excepto que la sesión es un archivo escrito en el servidor. lado, y el archivo de cookies también debe escribirse en el lado del cliente, pero el archivo donde está el número de su navegador. El estado de la sesión se almacena en el lado del servidor, y el cliente solo tiene la identificación de la sesión, mientras que el estado del Token; se almacena en el lado del cliente.
Para comprender completa y profundamente el Token, primero debemos comprender estos: el concepto de Token, el proceso de autenticación, las ideas de implementación, los escenarios de uso y las diferencias entre Cookie, Sesión y Token.
Definición del esquema de contenido de token
Token es una forma de verificar la identidad del usuario, denominado "token" para abreviar. El token más simple consta de: uid (la identidad única del usuario), tiempo (la marca de tiempo de la hora actual), signo (firma), que se compone de las primeras sales del token y está comprimido en una cierta longitud de caracteres hexadecimales. utilizando una cadena de hash, que puede evitar que terceros malintencionados unan solicitudes de token al servidor). También puede colocar parámetros sin cambios en el token para evitar múltiples comprobaciones de la base de datos. Proceso de autenticación de token
Cada solicitud requiere un token, que debe enviarse en el encabezado HTTP para garantizar que la solicitud HTTP no tenga estado. También configuramos la propiedad del servidor Access-Control-Allow-Origin: * para permitir que el servidor acepte solicitudes de todos los dominios.
Cabe señalar que cuando el encabezado ACAO está marcado (designando) *, no se deben incluir certificados como autenticación HTTP, certificado SSL de cliente y cookies. Idea de implementación del Token
Cuando autenticamos la información en el programa y obtenemos el Token, podemos hacer muchas cosas con este Token. Incluso podemos crear un token basado en permisos y pasarlo a aplicaciones de terceros, que pueden obtener nuestros datos (solo con el token específico que permitimos). Escenarios de aplicación de token La diferencia entre cookie y sesión
Según las consideraciones anteriores, la solución recomendada es:
La sesión y la cookie se complementan entre sí y se complementan entre sí y se utilizan juntos para combinar información importante, como la información de inicio de sesión. La información se almacena como Sesión. Si es necesario conservar otra información, se puede colocar en Cookie. La diferencia entre Token y Session
Session y Token no son contradictorios. Como autenticación de identidad, Token es más seguro que Session porque cada solicitud enviada por Token está firmada y puede evitar escuchas y escuchas. repetir ataques. La sesión debe depender de la capa de enlace para garantizar la seguridad de la comunicación. Como se mencionó anteriormente, si necesita implementar una sesión con estado, puede guardar algún estado en el lado del servidor agregando una sesión.
La aplicación suele utilizar Restful API para tratar con el servidor. El resto es sin estado, es decir, la aplicación no necesita usar cookies para guardar la sesión como el navegador, por lo que basta con usar el token de sesión para marcarla. La sesión/estado es manejado por la lógica del servidor API. Si el backend no es el resto de API de Stateless, es posible que deba guardar la sesión en la aplicación. Puede incrustar el webkit en la aplicación y usar un navegador oculto para administrar la sesión de cookies.
La sesión es una. Mecanismo de almacenamiento HTTP. El propósito es proporcionar un mecanismo de persistencia para HTTP sin estado. La llamada autenticación de sesión simplemente almacena información del usuario en la sesión. Debido a la imprevisibilidad del SID, se considera seguro por el momento.
La sesión sólo proporciona una autenticación simple, que tiene este SID y todos los derechos del Usuario. Deben mantenerse estrictamente confidenciales. Estos datos solo se guardan en el sitio donde se utilizan y no se pueden compartir con otros sitios web ni aplicaciones de terceros. En pocas palabras, si es posible que sea necesario compartir sus datos de usuario con un tercero, o permitir que un tercero llame a una interfaz API, use Token. Si es solo su propio sitio web o aplicación, se puede usar cualquier cosa.
Token se refiere a OAuth Token o un mecanismo similar, que proporciona autenticación y autorización. La autenticación es para los usuarios y la autorización es para la aplicación. El propósito es permitir que una Aplicación tenga derecho a acceder a la información de un usuario. El Token aquí es único y no se puede transferir a otras Aplicaciones ni a otros usuarios.
El token es un token. Por ejemplo, cuando autoriza (inicie sesión) un programa, es la base para determinar si ha autorizado el software. La cookie es un archivo txt escrito en el cliente, que registra el acceso del usuario, el inicio de sesión y otra información. La próxima vez que el usuario inicia sesión en un sitio web, el servidor recibe la solicitud y llama automáticamente a la cookie para iniciar sesión automáticamente con el nombre de usuario.
La sesión es similar a la cookie, excepto que la sesión es un archivo escrito en el lado del servidor y también es necesario escribir un archivo de cookie en el lado del cliente, pero el archivo contiene el número de navegador del usuario. de sesión se almacena en el lado del servidor. El cliente solo tiene la identificación de la sesión y el estado del token se almacena en el cliente.
Lo anterior es una introducción a los puntos de conocimiento sobre Token, Sesión y Cookie. Para obtener una explicación más detallada, si está interesado, puede consultar las 500 colecciones especiales de tecnología de arquitectura BAT. Sigo compartiendo. Responde a la arquitectura y podrás conseguirlo.
¿Qué es un token?
El token es un token, un certificado y una clave al realizar la verificación de identidad en el campo web, ¡el punto clave es la verificación! ! Cuando se trata de verificación, es necesario comprender el historial de desarrollo del campo web.
2. A medida que cambian las necesidades de las personas, como los sistemas de compras en línea, los sitios web que deben iniciar sesión, etc., se necesita interactividad en este momento cuando el servidor recibe la información. solicitud, debe Si ha iniciado sesión y para determinar quién es, le responderemos. En este momento, surge la pregunta de cómo saber quién solicita cada vez, por lo que sale una ID de sesión. , que es una cadena aleatoria. Cuando todos inician sesión, el servidor devolverá una ID de sesión. Al realizar la solicitud nuevamente, siempre que se proporcione la ID de la sesión, el servidor sabrá quién está solicitando.
3. De esta manera, todos solo necesitan guardar su propia identificación de sesión, ¡y el servidor necesita guardar la identificación de sesión de todos! ! ! Si miles de personas acceden al servidor, supondrá una gran sobrecarga para el servidor, lo que limitará seriamente la capacidad de expansión del servidor. Por ejemplo, si la máquina A y la máquina B forman un clúster de servidores, cuando se acceda a la máquina A, la máquina A se verá afectada. El ID de sesión está en la máquina A. Si se muda a la máquina B, ya no podrá acceder a ella. Tal vez diga, ¿qué pasa con copiar, mover la máquina A a la máquina B, y algunos dicen que coloque el logotipo en una máquina? uniformemente, pero si esta máquina cuelga, la experiencia será muy mala.
4. En este momento, algunas personas piensan que el usuario guarda su propia identidad, que es el Token. Al acceder, trae este Token. Este Token es la firma de identificación del usuario. Solo necesita el mismo algoritmo y servidor. Firme con la clave que acaba de aprender. Si el resultado es el mismo que la firma en el Token, se puede demostrar que es un usuario que ha iniciado sesión.
De esta manera, el servidor no guarda la identificación de la sesión. Solo necesita generar el token. Al acceder, solo necesita juzgar el token. El token también tiene un período de validez. También hay que renovarlo. ¿Cuáles son las diferencias entre los escenarios de uso de Token, Cookie y Sesión?
El token se utiliza principalmente para la autenticación de identidad en el campo web. La más común es la función Web API:
Cookie es una cookie que son datos producidos por el servidor y de forma permanente. almacenado en el navegador, con kv En forma de Luego actualice la página y busque cookies.
La sesión es un identificador de sesión, que el servidor utiliza para determinar quién es el usuario en la sesión. El número aleatorio generado por el servidor se guarda en el servidor y el cliente también debe guardarlo. Aunque la sesión se puede autenticar Sí, limita las capacidades de expansión del servidor. Al mismo tiempo, cuando el servidor está compuesto por más de dos máquinas, causará problemas de sincronización para las sesiones guardadas en más de dos máquinas, lo que provocará problemas de sincronización. conducir a una experiencia de usuario extremadamente pobre.
La mayor diferencia entre Token y Session es que no es necesario guardar el servidor Token y se implementa mediante firmas y otras tecnologías. Debido a que la sesión es un número aleatorio, el servidor debe guardarlo.