Token web JSON comprometido (JWT) Portador Token

Para responder a sus preguntas:

  

1) ¿Cómo maneja una situación con un secreto de token comprometido que se comparte entre un cliente y el servidor?

Añade una fecha de caducidad a tu token. Asegúrese de que el token no se pueda utilizar después de la fecha de caducidad. Pero esto no impide el acceso no autorizado dentro del período de caducidad del token.

Por lo tanto, para superar este problema, puede incrustar la dirección IP del cliente u otra información similar dentro del token. Y asegúrese de que la solicitud entrante con el token se utilice desde la misma dirección IP a la que se emitió.

  

2) ¿Cierra la sesión en todos sus clientes y define un nuevo secreto de token para futuras solicitudes? (eso sería una mala experiencia)

Si quiere cerrar sesión en todos los clientes que usan múltiples tokens de una manera autorizada, entonces No. Puede continuar usando múltiples tokens al mismo tiempo, siempre que tenga un período de caducidad finito para los tokens. Esto asegura que su token se utilice dentro de la ventana de tiempo prevista.

Pero, si te refieres a cuándo se roban el token y de alguna manera lo descubriste. Es mejor invalidar todos los tokens para ese usuario.

Sin embargo, es posible que desee tener un mecanismo que revoque todos los tokens explícitamente en casos especiales. Puede ser como cuando el usuario restablece su contraseña porque cree que su contraseña puede estar comprometida.

  

3) ¿Hay una manera de simplemente cerrar sesión en el cliente comprometido?

Puede ser, depende de su capacidad para identificar con precisión qué token se ha comprometido. Lo que puede llevar a que todos los clientes usen ese token para perder el acceso. Pero, no lo recomendaría. Pero, oye, siempre puedes escribir código que se vuelva a autenticar dinámicamente y obtener un nuevo token de acceso cuando el cliente anterior ya no pueda usar el token. :-)

No tenga miedo de invalidar un token cuando sea necesario. Si pierde un token, escriba un script dinámico para volver a autenticarse. Si cree que puede perder los detalles de la sesión cuando use un token nuevo, vuelva a enviar el token caducado al servidor mientras se vuelve a autenticar. Usando este token caducado, puede reconstruir un token nuevo con los detalles de la sesión del token anterior. Siempre que haya incrustado los detalles de la sesión en el token caducado.

Si desea poder revocar tokens previamente otorgados antes de su fecha de caducidad (un problema de seguridad válido), deberá incluir una búsqueda en la base de datos que anule una de las principales ventajas de JWT, por lo que podría decide no usarlos en primer lugar.

Aquí hay un artículo que habla sobre este caso: enlace

En mi caso, también estoy almacenando los tokens en mi base de datos.

Durante la autenticación inicial, el usuario envía la contraseña del nombre de usuario. Las credenciales se verifican y luego genero el token que también se almacena en la base de datos y también envío el token al cliente. En cada solicitud de cliente, verifico si el token también existe para ese usuario en mi base de datos.

Si el cliente cierra la sesión y quiere revocar el token, simplemente lo quito de la tabla de identidades.

Los tokens JWT se pueden decodificar y toda la información se puede leer en formato json, por ejemplo:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

La primera parte es el encabezado: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

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

La segunda parte es Carga útil: eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

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

La última parte es la firma que se creó como:

//In our example, the algorithm is (HS256)
signature = algorithm(hash of (header + payload), secret)

Ahora, es la clave que solo se oculta dentro de la firma del token, luego, llegamos a la conclusión de que:

1. La CLAVE debe mantenerse en un lugar seguro y no debe ser revelada a nadie.
2. Si el token JWT se usa para la autenticación, debe usarse sobre SSL / TLS.
3. No se podrá confiar en el token JWT sin la validación de signature con clave secreta.
4. El EMISOR del token JWT no debe colocar información confidencial dentro del token JWT en caso de que solo se firme la información utilizada con JWT.

akajas

  

1) ¿Cómo maneja una situación con un secreto de token comprometido que es   compartido entre un cliente y el servidor?

use SSL / TLS (conexión segura) y expire cada token de acuerdo con su sistema de inicio de sesión. El token JWT se debe utilizar como permanente, cada vez que el usuario inicie sesión en crear el token JWT.

  

2) ¿Desconecta a todos sus clientes y define un nuevo token secreto para   futuras peticiones? (eso sería una mala experiencia)

Si se compromete su clave secreta, debe crear una nueva clave secreta definitivamente y renovar las sesiones activas emitiendo el cierre de sesión y forzando al sistema a volver a autenticar a todos los usuarios activos.