En un artículo anterior, hablé sobre los conceptos básicos de JWT . Si está en sus dedos, entonces esta es solo la llave con la que abrimos la puerta a los recursos privados. Pero, ¿qué pasa si se roba esta clave (más precisamente, harán un duplicado). Entonces, alguien más podrá iniciar sesión en el servidor con su nombre, y es posible que ni siquiera lo sepamos. No queremos permitir tal escenario. Pero que hacer?
Aumentar la seguridad
Sugiero a los lectores, antes de continuar de forma independiente, que piensen en lo que podemos hacer con la seguridad.
Aquí hay algunos enfoques que pueden mejorar la seguridad. Puede escribir en los comentarios qué otros enfoques existen; los agregaré.
- Usando el protocolo
https , que protege el canal de datos a través de Internet. De hecho, este es un contenedor sobre http , que impone protocolos criptográficos adicionales: SSL y TLS - Agregar información de
IP a la payload . Entonces el token de otras IP no pasará la verificación. Pero la IP puede ser falsa y qué hacer con IP direcciones IP dinámicas o cuando un usuario se conecta desde un teléfono en un café o metro. Por lo tanto, no usaremos este enfoque. - Use
RS256 . Esto garantiza la seguridad de la clave privada en sí. Pero con los tokens, todo permanece absolutamente como estaba. Necesitamos RS256 cuando tenemos miedo de pasar la clave secreta a otros servidores, lo que puede no ser confiable. Solo les damos una herramienta de autenticación de token, que es absolutamente inútil para un atacante. - Usa tokens de corta duración. Pero el usuario tendrá que volver a iniciar sesión cada vez que caduque. El usuario tarde o temprano se aburrirá y dejará nuestro recurso.
- Pero, ¿qué pasa si usa tokens de corta duración de todos modos, pero le da otro token, cuyo propósito es solo obtener un nuevo token de corta duración sin una nueva autorización? Tal token se llama token de actualización y será posible usarlo solo una vez. Este será mi artículo.
Recordemos qué es JWT
JWT aprovecha los JWE codificación JWS (Firma) y JWE (Cifrado). La firma no permite que alguien falsifique un token sin información sobre la clave secreta, y la codificación protege contra la lectura de datos por parte de terceros.
Veamos cómo pueden ayudarnos a autenticar y autorizar al usuario en el sitio.
Autenticación (autenticación en inglés; del griego. Αὐθεντικός [authentikos] - real, auténtico; de αὐθέντης [Autores] - el autor) - procedimiento de autenticación. En nuestro caso, verificamos el inicio de sesión + contraseña para una coincidencia con la entrada en la base de datos de datos del usuario.
Autorización (autorización en inglés - permiso, autorización) - otorgando al usuario el derecho de realizar ciertas acciones; y también el proceso de verificar (confirmar) estos derechos cuando se intenta realizar estas acciones.
En otras palabras, la autenticación verifica la legalidad del usuario, y luego, si todo está bien, el usuario se autoriza, es decir, puede realizar acciones permitidas con la base de datos. Por lo general, estos dos procesos se combinan y, por lo tanto, existe una confusión bien conocida.
Tipos de fichas
- Los tokens de acceso (JWT) son tokens que se pueden usar para acceder a recursos protegidos. Son de corta duración , pero reutilizables . Pueden contener información adicional, como la vida útil o
IP dirección IP de donde proviene la solicitud. Todo depende del deseo del desarrollador. - Token de actualización (RT) : estos tokens realizan solo una tarea específica: obtener un nuevo token de acceso. Y esta vez no puede prescindir de un servidor de autorización. Son longevos , pero desechables .
El caso de uso principal es el siguiente: tan pronto como expire el viejo JWT , ya no podemos recibir datos privados con él, luego enviamos RT y recibimos un nuevo par de JWT+RT . Con el nuevo JWT nuevamente podemos recurrir a recursos privados. Por supuesto, un token de actualización también puede ir mal, pero no sucederá pronto, porque vive mucho más tiempo que su hermano.
La idea clave de la separación de tokens es que, por un lado , los tokens de autorización nos permiten verificar fácilmente a un usuario sin un servidor de autorización, simplemente comparando firmas.
const validateToken = token => { const [ header, payload, signature ] = token.split('.'); return signature === HS256(`${header}.${payload}`, SECRET_KEY); }
Por otro lado , tenemos una
En conclusión
Gracias a este enfoque, reducimos el retraso de tiempo para acceder al servidor de latency , y la lógica del servidor en sí se vuelve mucho más simple. Y desde un punto de vista de seguridad, si nos robaron un token de acceso, solo un tiempo limitado podrá usarlo, no más de su vida útil. Para que un atacante pueda usar más tiempo, también necesitará robar una actualización, pero el usuario real sabrá que ha sido pirateado porque será expulsado del sistema. Y una vez que dicho usuario inicie sesión nuevamente, recibirá un par actualizado de JWT+RT , y los robados se convertirán en una calabaza.
Enlaces utiles
- ¿Por qué necesito Actualizar token si tengo token de acceso?
- Actualizar tokens: cuándo usarlos y cómo interactúan con los JWT
- Más sorpresas de OAuth 2.0: el token de actualización