¿Qué es un token? En comparación con la sesión y las cookies, ¿cuáles son las diferencias en los escenarios de uso?
La finalidad de Cookie y Sesión es saber si accedemos al sitio web mediante protocolo HTTP o protocolo HTTPS. El protocolo HTTP en sí no tiene estado (es decir, el servidor no puede saber qué solicitudes provienen del mismo cliente). La capa empresarial implica la interacción entre el cliente y el servidor (los datos se pueden compartir entre varias páginas del mismo sitio web). En este punto, el servidor debe mantener el estado de la sesión para 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.
Normalmente, las sesiones y las cookies se utilizan juntas.
¿Qué significa el token de sesión y mecanismo de cookies mencionado anteriormente para mantener la sesión? Surgirá un problema: el navegador del cliente solo necesita guardar su propio ID de sesión, mientras que el servidor necesita guardar la información de sesión de todos los usuarios, lo cual es muy costoso para el servidor y no utiliza extensiones de servidor (como cómo sincronizar el almacenamiento cuando el servidor está agrupado) ¡La conversación es un problema)!
Entonces, algunas personas piensan que si el cliente conserva la información de la sesión y no puede falsificarse, ¿no se resolvería este problema? Luego está el mecanismo del token.
El token, comúnmente conocido como "token", consta de las siguientes partes:
El proceso de autenticación bajo el mecanismo del token es en realidad muy similar al mecanismo de cookies e incluye principalmente lo siguiente procesos:
p>
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. Una vez que el cliente recibe el token, se guarda en el cliente (se puede guardar en Cookie, LocalStorage, SessionStorage
3. , Coloque el token en el encabezado de la solicitud como encabezado de solicitud
4. El servidor recibe el token en el encabezado de la solicitud y firma nuevamente los parámetros del usuario de acuerdo con las reglas establecidas. Si las dos firmas son consistentes, se considera exitoso; de lo contrario, la solicitud de manipulación de datos falla.
(Ejemplo de generación de firma)
(Ejemplo de verificación de firma)
La diferencia entre token y cookie de sesión La cookie en realidad actúa como un token, pero "tiene" estado "; El token no tiene estado, lo que favorece más la implementación distribuida.
Sesión y cookie Antes de hablar de Token, hablemos brevemente de qué son la sesión y la cookie.
Token Pero aquí hay un problema. Le costaría mucho al servidor guardar la información de la sesión para todos los usuarios. Si está en una arquitectura distribuida, debe considerar compartir * * * la sesión, lo que requiere diseño y desarrollo adicionales, como guardar la información de la sesión en Redis para * * * compartir, por esta razón, algunos; la gente considera esto Si el cliente puede guardar la información, si se puede guardar en cualquier lugar y si su seguridad está garantizada, entonces está el Token.
El token es una cadena generada por el servidor y puede considerarse como el token utilizado por el cliente para realizar solicitudes.
El flujo general del proceso de autenticación basado en token es el siguiente:
En resumen, ¡espero que mi respuesta pueda ayudarte! Continuaré compartiendo mis puntos de vista sobre el desarrollo de Java, el diseño de arquitectura, el desarrollo profesional de programadores, etc., con la esperanza de llamar la atención de todos.
Token, como su nombre indica, es un token, certificado y clave. Sólo con esta llave podrás abrir la puerta. El token suele ser generado por el servidor.
Por ejemplo, en un sistema web, cuando un usuario inicia sesión, después de que el servidor verifica que el nombre de usuario y la contraseña han pasado, también se generará un token, un refresco y un tiempo de vencimiento. Luego, refrescoToken y 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 o ha caducado. Si el token no existe o caduca, la solicitud será rechazada. ¿Qué hacer si el token caduca? Simplemente use refrescoToken para actualizar la hora. Por supuesto, aquí puede haber otras opciones. Por ejemplo, solo se genera un token y el tiempo de vencimiento se actualiza cada vez que se solicita. Si el tiempo de vencimiento no se actualiza durante un período prolongado, el token caducará.
La sesión es una respuesta y una operación del servidor. Cuando visita un sitio web por primera vez, el servidor generará una sesión con una identificación de sesión correspondiente. Esta sesión se almacena en la memoria y puede escribir información en esta sesión, como información sobre el usuario que ha iniciado sesión actualmente. El Sessionid se devolverá al cliente y el cliente normalmente lo guarda con una cookie. Por supuesto, no es necesario escribir esta cookie manualmente. Tome el contenedor Tomcat como ejemplo. Cuando el backend llama al método getSession del objeto HttpServletRequest, Tomcat generará internamente un JSESSONID (el nombre del ID de sesión de Tomcat). Este jsessonid se devolverá al cliente con esta solicitud. Información del encabezado de respuesta
Este jessionid se escribirá en la cookie. Luego, jessionid se pasará al servidor a través de una cookie.
Aquí queda claro que los datos de la sesión se almacenan en la memoria. Ese es el problema. Si nuestro servicio está distribuido y tiene varias máquinas, podemos almacenar la información del usuario en la sesión cuando iniciamos sesión por primera vez, pero las solicitudes posteriores van a la máquina B y la máquina B no puede obtener la sesión del usuario. Además, la sesión se almacena en la memoria y se pierde cuando se reinicia el servidor. Esta es su desventaja. Actualmente existen algunas tecnologías, como el uso compartido de sesiones, iphash y la persistencia de sesiones, 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 una 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. Estas cookies se llevan a cabo con cada solicitud. El servidor puede identificar el origen de la solicitud obteniendo la información de la cookie del encabezado de la solicitud, de modo que http tenga estado.
Las siguientes son algunas cosas a tener en cuenta sobre las cookies.
1. Las cookies se almacenan en el lado del cliente, por lo que no son seguras. Los humanos pueden borrarlo.
2. Las cookies tienen configuración de tiempo de caducidad. Si no se establece el tiempo de vencimiento, significa que esta cookie es el tiempo de sesión del navegador actual. La cookie existe cuando se cierra el navegador. Si hay fecha de caducidad, la cookie se almacenará en el disco duro y no se verá afectada cuando se cierre el navegador. La próxima vez que abra su navegador, la cookie seguirá allí.
3. El tamaño de las cookies está limitado a 4 KB.
Hay muchas respuestas a esta pregunta en Internet. Creo que los he leído todos, pero no creo entenderlos. Así que no plagiaré en línea. Usaré mis propias palabras, intentaré ser lo más simple posible e ir al grano.
Cookie y 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. La forma más común es que la cookie del cliente solo almacene una ID de sesión. La ID de sesión es un número aleatorio sin reglas y el servidor la genera aleatoriamente después de que el cliente inicia sesión.
En el futuro, cada vez que el cliente visite el sitio web, traerá esta cookie que consiste en el ID de sesión. 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 almacenar en la memoria o en una base de datos (normalmente una base de datos en memoria).
Los tokens, por otro lado, permiten que el servidor no guarde ninguna información de inicio de sesión.
El proceso del token es así. Después de que el cliente inicia sesión, el servidor genera una gran cantidad de información de identidad del cliente, incluido el nombre de usuario, el grupo de usuarios, los permisos, el tiempo de vencimiento, etc. Además, firme la información. Luego, la información de identidad y la firma se envían al cliente en su conjunto. Todo esto se llama ficha. El cliente es entonces responsable de guardar el token, el servidor no. Cada vez que un cliente visita el sitio web, trae consigo este token. Una vez que el servidor recibe la solicitud, la separa en información de identidad y una firma, y luego verifica la firma. Si la verificación es exitosa, la información de identidad (nombre de usuario, grupo de usuarios, permisos, etc.) se usa directamente.
Se puede ver que, en comparación con el mecanismo de cookie/sesión, en el mecanismo de token, el servidor no necesita guardar al usuario. La información de identidad (nombre de usuario, grupo de usuarios, permisos, etc.) no existe en absoluto. Esto reduce la carga en el servidor.
Por ejemplo, actualmente hay 10 millones de usuarios conectados y visitando diferentes páginas web. Si se utilizan cookies/sesión, la información de 100.000 usuarios debe registrarse en la memoria del servidor (o base de datos en memoria) al mismo tiempo. Cada vez que un cliente accede a una página, el servidor consulta la memoria para obtener su información de inicio de sesión. Si se utiliza un token, la información de inicio de sesión del usuario no se registra 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 dice quién es el cliente. Token es como me llaman mis clientes. Por supuesto, los tokens tienen un mecanismo de firma. Si el cliente falsifica su identidad, la firma no se realizará. Este algoritmo de firma es muy simple: consiste en agregar un valor salt (que no se puede filtrar) que solo el servidor conoce a la información de identidad del cliente, y luego realizar el algoritmo hash md5 (esto es simple y fácil de entender, en realidad). los detalles son un poco más complicados).
La cookie/sesión es relativamente simple en 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 esta información en la memoria se perderá en caso de un apagado. Los tokens no tienen tales problemas porque el servidor no guarda la identidad del usuario. Ésta es la ventaja del token.
Token Debido a que el servidor no almacena información de identidad del usuario, todo depende de la firma original. Por tanto, existe riesgo de robo. En otras palabras, una vez robado, es posible que el servidor no pueda hacer nada porque sólo reconoce algoritmos de firma. También hay un mecanismo de sesión: el servidor puede expulsarlo (eliminarlo de la memoria) en cualquier momento para ver quién no está contento. Por lo tanto, los tokens dependen en gran medida del tiempo de vencimiento. El tiempo de vencimiento no puede ser demasiado largo. Un vencimiento corto reduce el riesgo de robo.
Además de lo anterior, personalmente creo que si el sistema desarrollado es lo suficientemente pequeño, tiendo a utilizar cookies/sesión. Si el sistema tiene muchos usuarios que inician sesión simultáneamente, servidores agrupados y requisitos de inicio de sesión único, tiende a utilizar tokens.
La historia del desarrollo de los tokens de la World Wide Web, un token, un 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:
Los sitios web utilizan principalmente cookies para almacenar temporalmente datos en el navegador, incluidos los datos de la caché del navegador y del servidor. Algunos datos se almacenan principalmente en el navegador.
Session se utiliza principalmente para guardar datos de la sesión, generalmente almacenados en el lado del servidor. Al mismo tiempo, cada par de sesiones utiliza un ID de sesión, que se almacena en la cookie del navegador.
El inicio de sesión y la autenticación de sesión tradicionales se implementan principalmente a través de sesiones y cookies. Con el rápido desarrollo de los sistemas distribuidos, especialmente las aplicaciones de microservicios, los mecanismos de acceso autorizado de tokens y cookies se están volviendo cada vez más populares. Normalmente, después de que el usuario inicia sesión, el servidor genera un token de acceso y el navegador almacena la cookie del token. Cada vez que se solicita un recurso, el token se lleva en el encabezado de la solicitud para el acceso autorizado al servidor.
Los tokens y las sesiones son soluciones para el mantenimiento y la autenticación de sesiones de sitios web.
Si son todos iguales ¿por qué hay tokens?
Comience desde el backend del token, 1. La aplicación móvil invalida la sesión del servidor.
2. Las sesiones no se pueden compartir en sistemas distribuidos.
Entonces la sesión no es válida para las dos situaciones anteriores, por lo que hay una declaración Token.
Entonces, ¿qué es un token? ¿Qué token y cómo se ve el token? Primero déjame darte una sensación intuitiva.
Token: PC-3066014fa 0b 10792 e4a 762-23-20170531133947-4f 6496
Para decirlo sin rodeos, el token guarda la información del usuario (las contraseñas y otra información confidencial no se pueden guardar).
Composición del token:
ID de cliente-código de usuario-id de usuario-fecha de creación-rondem [6 dígitos]
CÓDIGO DE USUARIO, RONDEM[6 bits] se convierte en el cadena anterior después del cifrado MD5.
Proceso de solicitud de token
Análisis del proceso de solicitud
1. El usuario front-end envía información de inicio de sesión al sistema de autenticación.
2. Verifique la información de inicio de sesión del usuario y determine si el usuario existe.
3. Si el usuario existe, genere información del token (ID de cliente-código de usuario-ID de usuario-fecha de creación-Rondem [6 dígitos]) y guárdela en redis.
4. Devuelva el token a la interfaz y añádalo al encabezado.
Validar cliente de token
Agregar el token al encabezado.
Servidor de red informática
Finalmente, para resumir
Generalmente, no hay problema en usar Session para proyectos de arquitectura vertical, pero se consideran tokens para proyectos distribuidos o terminales móviles.
Conferencia
La traducción china de sesión es "conversación". Cuando un usuario abre una aplicación web, se genera una sesión con el servidor web. El servidor utiliza la sesión para guardar 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 la carga del servidor web está equilibrada, la sesión se perderá cuando la siguiente solicitud de operación llegue a otro servidor.
Cookies
Las cookies son datos almacenados en el terminal local. Las cookies son generadas por el servidor y enviadas al navegador. El navegador guarda la cookie en forma de kv en un archivo de texto en un directorio determinado y envía la cookie al servidor la próxima vez que solicita el mismo sitio web. Dado que las cookies existen en el lado del cliente, el navegador ha agregado algunas restricciones para garantizar que las cookies no se utilicen de forma maliciosa y ocupen demasiado espacio en el disco, por lo que la cantidad de cookies para cada dominio es limitada.
La cookie consta de: nombre (clave), valor (valor), dominio válido (dominio), ruta (generalmente configurada en global: ""), tiempo de vencimiento, indicador de seguridad (después de especificar, use solo SSL conexión, la cookie se enviará al servidor (https)).
El siguiente es un ejemplo simple de js usando cookies:
Cookie generada cuando el usuario inicia sesión:
document cookie = " id = " result data[' id '] ". ; ruta =/;
document. cookie = " nombre = " resultado. datos[' nombre '] "; ruta =/;
document. cookie = " avatar = " resultado . data [' avatar '] "path =/;
Cuando utilice cookies, realice el siguiente análisis:
var cookie = document.cookievar cookierar = cookie.split("; ") ; var usuario _ info = { }; for (var I = 0; I ltcookier er . length; i ) {
usuario _ info[cookier er[I].split(" = "[ 0] ]= cookier[I].split(" = "[1];
}
$('#user_name ').text(user_info[' nombre ']) ;
$('#user_avatar '). attr("src", user_info['avatar']);
$('#user_id '). ']);
Token
Token significa "token" y es una forma de verificar la identidad del usuario. El token más simple consta de uid(. La identidad única del usuario), hora (. marca de tiempo de la hora actual) y signo (firma, los primeros dígitos del token salt se comprimen en una cadena hexadecimal de cierta longitud a través de un algoritmo hash, que puede evitar que terceros malintencionados empalmen el servidor de solicitudes de token). coloque parámetros constantes en el token para evitar verificar la base de datos varias veces
La diferencia entre cookies y sesiones
1. se almacena en el servidor.
2. Las cookies no son muy seguras. También hay personas que pueden analizar las cookies almacenadas localmente y las cookies falsas.
Por razones de seguridad, utilice una sesión.
3. La sesión se guardará en el servidor por un período de tiempo. Cuando el acceso aumenta, consume el rendimiento del servidor.
Considerando reducir el rendimiento del servidor, se debe utilizar COOKIE.
4. Los datos guardados por una sola cookie no pueden exceder los 4K y muchos navegadores limitan un sitio para guardar hasta 20 cookies.
5. Entonces, mi sugerencia personal:
Guarde la información importante, como la información de inicio de sesión, como una sesión.
Si necesita guardarlo, se puede colocar otra información en COOKIE.
La diferencia entre token y sesión
No existe contradicción entre sesión y token oauth. Como token de autenticación, su seguridad es mejor que la de una sesión porque cada solicitud está firmada, lo que evita ataques de interceptación y reproducción, mientras que una 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.
La aplicación generalmente usa Restful API para manejar el servidor.
El resto no tiene estado, es decir, la aplicación no necesita usar cookies para guardar la sesión como un navegador, basta con marcarse con un token de sesión y la sesión/estado es manejado por la lógica del servidor API. Si su backend no es una API REST sin estado, es posible que deba guardar la sesión en la aplicación. Puede integrar webkit en su aplicación y utilizar un navegador oculto para administrar las sesiones de cookies.
Una sesión es un mecanismo de almacenamiento HTTP diseñado para proporcionar un mecanismo de persistencia para HTTP sin estado. La llamada autenticación de sesión consiste en almacenar información del usuario en la sesión. Debido a la imprevisibilidad del SID, se considera seguro temporalmente. Este es un medio de autenticación. El token, si se refiere a un token de OAuth o un mecanismo similar, proporciona autenticación y autorización. La autenticación es para el usuario y la autorización es para la aplicación. Su propósito es dar a las aplicaciones acceso a la información del usuario. El token aquí es único. No se puede transferir a otras aplicaciones ni a otros usuarios. Date la vuelta y conversa. La sesión solo proporciona una autenticación simple, es decir, tener este SID significa tener todos los permisos de este usuario. Esto requiere una estricta confidencialidad. Estos datos solo deben conservarse en el sitio web y no deben compartirse con otros sitios web o 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, utilice Token. Si siempre has tenido tu propio sitio web y tu propia aplicación, entonces no importa lo que uses.
El token es un token. Por ejemplo, si autoriza (inicie sesión) un programa, es una base para juzgar si ha autorizado el software; la cookie es un archivo txt escrito en el cliente, que contiene. 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 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. También debe escribir un archivo de cookies en el lado del cliente, pero el archivo contiene la ID 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; el estado del token se almacena en el lado del cliente.
Para tener una comprensión completa y profunda de Token, primero debe comprender lo siguiente: 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. .
Esquema del contenido La definición de token es una forma de verificar la identidad de un usuario, denominada "token". El token más simple consta de: uid (la identidad única del usuario), hora (la marca de tiempo de la hora actual) y signo (firma). Los primeros números del token salt se comprimen en una cadena hexadecimal de cierta longitud. un algoritmo hash, que puede evitar que terceros malintencionados unan solicitudes de token al servidor). También puede poner parámetros constantes en el token para evitar verificar la biblioteca varias veces.
Cada solicitud durante el proceso de autenticación requiere un Token. El Token debe enviarse en el encabezado HTTP, garantizando así que la solicitud HTTP no tenga estado. También configuramos la propiedad del servidor Access-Control-Allow-Origin:* para permitir que el servidor reciba solicitudes de todos los dominios.
Cabe señalar que cuando el encabezado ACAO está marcado con *, no se permiten la autenticación HTTP, los certificados SSL del cliente, las cookies y otros certificados.
Idea de implementación del token: cuando autenticamos la información en el programa y obtenemos el token, podemos usar este token para hacer muchas cosas. Incluso podemos crear un token basado en permisos y enviarlo a aplicaciones de terceros, que pueden obtener nuestros datos (solo en el token específico que permitimos, por supuesto).
Escenarios de aplicación de Token: la diferencia entre Cookie y Sesión
Con base en las consideraciones anteriores, se recomienda lo siguiente:
Sesión y Cookie se complementan entre sí y deben usarse juntos.
La información importante, como la información de inicio de sesión, se almacena como Sesión, y también se puede almacenar otra información en Cookies si es necesario conservarla.
La diferencia entre token y sesión
La sesión y el token no son contradictorios. Como autenticación, Token es más seguro que Session porque cada solicitud enviada por Token está firmada, lo que puede evitar ataques de interceptación y reproducción. Las sesiones deben 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 manejar el servidor. Rest es stateless, es decir, la App no necesita utilizar cookies para guardar la sesión como un navegador, basta con marcarla con un token de sesión. La sesión/estado es manejado por la lógica del servidor API. Si el backend no es una API rest sin estado, es posible que necesite guardar la sesión en la aplicación. Puede incrustar webkit en la aplicación y utilizar un navegador oculto para administrar las sesiones de cookies.
Una sesión es un mecanismo de almacenamiento HTTP diseñado para proporcionar un mecanismo de persistencia para HTTP sin estado. La llamada autenticación de sesión consiste en almacenar información del usuario en la sesión. Debido a la imprevisibilidad del SID, se considera temporalmente seguro y un medio de autenticación.
La sesión sólo proporciona autenticación simple, es decir, tiene todos los permisos de este SID y usuario. Esto requiere una estricta confidencialidad. Estos datos solo se almacenan en el sitio web del usuario y no se pueden compartir con otros sitios web o 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, utilice Token. Si es solo tu propio sitio web o aplicación, puedes usar cualquier cosa.
Token se refiere a un token de OAuth 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. Su propósito es dar a las aplicaciones acceso a la información del 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, si autoriza (inicie sesión) un programa, es una base para juzgar si ha autorizado el software. La cookie es un archivo de texto escrito en el lado del cliente, que registra el acceso, el inicio de sesión y otra información del usuario. La próxima vez que el usuario inicie sesión en el sitio web, el servidor llamará automáticamente a la cookie e iniciará sesión con el nombre de usuario cuando se reciba una solicitud.
La sesión es similar a la cookie, excepto que la sesión es un archivo escrito en el lado del servidor, mientras que el archivo cookie debe escribirse en el lado del cliente, pero el archivo contiene el número de navegador del usuario. El estado de la 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 lado del cliente.
Lo anterior es una introducción a los puntos de conocimiento de Token, Sesión y Cookie, así como una explicación más profunda y detallada. Los niños interesados pueden ver la colección 500 de tecnología de arquitectura BAT que continuaré compartiendo, y pueden obtenerla respondiendo a la arquitectura.
¿Qué es Token? Un token es un token, un certificado y una clave. ¡La clave para la autenticación en el dominio web es la autenticación! ! Se dice que la verificación requiere comprender la historia de desarrollo del campo Web.
2. A medida que cambian las necesidades de las personas, como los sistemas de compras en línea y los sitios web que requieren inicio de sesión, se necesita interacción en este momento. Cuando el servidor recibe la solicitud, debería responderle en función de si ha iniciado sesión y quién es. En este momento llega el problema. ¿Cómo saber quién solicita cada vez? Esto genera una identificación de sesión, que es una cadena aleatoria. Cuando todos hayan iniciado sesión, el servidor devolverá uno.
3. De esta manera, todos solo necesitan guardar su propia ID de sesión y el servidor necesita guardar la ID de sesión de todos. ! ! Si miles de personas acceden al servidor, supondrá una gran sobrecarga para el servidor, lo que limitará seriamente la escalabilidad del servidor. Por ejemplo, si la máquina A y la máquina B forman un clúster de servidores, se accede a la máquina A y el identificador de sesión está en la máquina A. Si se transfiere a la máquina B, no se puede acceder a ella.
Tal vez dirás, ¿qué pasa con el plagio? La máquina A pasa a la máquina B. Algunas personas dicen que los identificadores están unificados en una máquina, pero ¿qué pasa si esta máquina cuelga?
4. En este momento, algunas personas piensan que el usuario ha guardado su identidad, es decir, el Token, y trae este Token cuando visita. Este token está firmado por identificación de usuario. Al autenticarse, el servidor solo necesita el mismo algoritmo y clave que conoce. Si el resultado es el mismo que la firma en el token, se demuestra que es el usuario que inició sesión.
De esta forma, el servidor no guarda el id de sesión y solo genera un token. Durante el acceso, siempre que se juzgue el token, el token también es válido, por lo que es necesario actualizar el token.
¿Cuál es la diferencia entre tokens, cookies y sesiones? El token se utiliza principalmente para la autenticación en el campo web. La función más utilizada es la API web:
Las cookies son cookies, que son datos generados por el servidor y se almacenan permanentemente en el navegador. En forma de kv, puede abrir su navegador (aquí se usa win10 edge como ejemplo), hacer clic en el botón de tres puntos de arriba, hacer clic en más herramientas, luego hacer clic en herramientas de desarrollador y luego hacer clic en red. En este punto, seleccione el documento para el contenido y actualice la página para encontrar las cookies.
La sesión es un identificador de sesión que el servidor utiliza para determinar con quién está conversando el usuario. Los números aleatorios generados por el servidor se guardan en el servidor y el usuario también debe guardarlos. Aunque la función * * * de la sesión se puede realizar, limita la capacidad de expansión del servidor. Al mismo tiempo, cuando el servidor consta de más de dos máquinas, se producirán problemas de sincronización de las sesiones guardadas por más de dos máquinas, lo que provocará una mala experiencia del usuario.
La mayor diferencia entre tokens y sesiones es que no es necesario guardar el servidor de tokens y se implementa mediante firmas y otras tecnologías. Debido a que la sesión es un número aleatorio, el servidor necesita guardarla.