REST API de seguridad Token almacenado vs JWT vs OAuth

Considera el primer caso. Cada cliente obtiene una identificación aleatoria que dura la duración de la sesión, lo que podría ser de varios días si lo desea. Luego almacena la información relevante para esa sesión en algún lado del servidor. Podría estar en un archivo o una base de datos. Supongamos que pasa el ID a través de una cookie, pero podría usar la URL o un encabezado HTTP.

ID de sesión / Cookies

Pros:

• Es fácil codificar el cliente y el servidor.
• Es fácil destruir una sesión cuando alguien se desconecta.

Cons:

• El lado del servidor debe eliminar periódicamente las sesiones caducadas en las que el cliente no se desconectó.
• Cada solicitud HTTP requiere una búsqueda en el almacén de datos.
• Los requisitos de almacenamiento crecen a medida que más usuarios tienen sesiones activas.
• Si hay varios servidores HTTP front-end, los datos de la sesión almacenados deben ser accesibles para todos ellos. Esto podría ser un poco más de trabajo que almacenarlo en un servidor. Los problemas más importantes son que el almacén de datos se convierte en un punto único de falla y puede convertirse en un cuello de botella.

Fichas web JSON (JWT)

En el segundo caso, los datos se almacenan en un JWT que se transmite en lugar de en el servidor.

Pros:

• Los problemas de almacenamiento del lado del servidor han desaparecido.
• El código del lado del cliente es fácil.

Cons:

• El tamaño de JWT podría ser mayor que un ID de sesión. Podría afectar el rendimiento de la red, ya que se incluye con cada solicitud HTTP.
• El cliente puede leer los datos almacenados en el JWT. Esto puede ser un problema.

• El lado del servidor necesita código para generar, validar y leer JWT. No es difícil, pero hay una pequeña curva de aprendizaje y la seguridad depende de ello.

  Cualquier persona que obtenga una copia de la clave de firma puede crear JWT. Es posible que no sepa cuándo sucede esto.

  Hubo (¿es?) un error en algunas bibliotecas que aceptaron cualquier JWT firmado con el algoritmo "ninguno" para que cualquiera pueda crear JWT en los que el servidor confíe.

• Para revocar un JWT antes de que caduque, debe utilizar una lista de revocaciones. Esto te lleva de nuevo a los problemas de almacenamiento del lado del servidor que intentabas evitar.

OAuth

A menudo, OAuth se utiliza para la autenticación (es decir, la identidad), pero se puede usar para compartir otros datos, como una lista de contenido que el usuario ha comprado y tiene derecho a descargar. También se puede utilizar para otorgar acceso para escribir en datos almacenados por terceros. Puede usar OAuth para autenticar usuarios y luego usar el almacenamiento del lado del servidor o JWT para los datos de la sesión.

Pros:

• No hay código para que los usuarios se registren o restablezcan su contraseña.
• No hay código para enviar un correo electrónico con un enlace de validación y luego validar la dirección.
• Los usuarios no necesitan aprender / escribir otro nombre de usuario y contraseña.

Cons:

• Depende del tercero para que sus usuarios utilicen su servicio. Si su servicio deja de funcionar o lo interrumpen, entonces necesita resolver algo más. Por ejemplo, ¿cómo migra los datos de la cuenta del usuario si su identidad cambia de "[email protected]" a "[email protected]"?
• Por lo general, debe escribir un código para cada proveedor. Por ejemplo, Google, Facebook, Twitter.
• Usted o sus usuarios pueden tener problemas de privacidad. Los proveedores saben cuál de sus usuarios usa su servicio.
• Confía en el proveedor. Es posible que un proveedor emita tokens que son válidos para un usuario a otro. Esto podría ser con fines legales o no.

Misceláneo

• Tanto los ID de sesión como los JWT pueden ser copiados y utilizados por múltiples usuarios. Puede almacenar la dirección IP del cliente en un JWT y validarla, pero eso evita que los clientes se muevan de forma móvil, por ejemplo, de Wi-Fi a celular.

Pregúntese por qué necesita invalidar el token original.

Un usuario inicia sesión, se genera un token y se apaga la aplicación.

El usuario presiona cerrar sesión, se genera un nuevo token y reemplaza el token original. Una vez más, todo está bien.

Parece que te preocupas por el caso en el que ambos tokens cuelgan. ¿Qué sucede si el usuario cierra la sesión y de alguna manera realiza una solicitud utilizando el token de inicio de sesión? ¿Qué tan realista es este escenario? ¿Es solo un problema durante el cierre de sesión o hay muchos escenarios posibles donde múltiples tokens pueden ser un problema?

Yo mismo no creo que valga la pena preocuparse. Si alguien está interceptando y decodificando sus datos https cifrados, tiene problemas mucho mayores.

Puedes darte protección adicional al poner un tiempo de caducidad en el token original. Entonces, si termina siendo robado o algo así, solo sería bueno por un corto período de tiempo.

De lo contrario, creo que necesitarías tener información de estado en el servidor. No incluya en la lista negra los tokens, sino que incluya en la lista blanca la firma del token actual.

Puede manejar los problemas de JWT que mencionó al almacenar un valor de sal junto con el usuario y usar la sal como parte del token para el usuario. Luego, cuando necesite invalidar el token, simplemente cambie el salt.

Sé que han pasado un par de años, pero ahora lo haría de forma diferente. Creo que me aseguraría de que los tokens de acceso tuvieran una vida relativamente corta, por ejemplo, una hora. También me aseguraría de usar tokens de actualización que tuvieran estado en el servidor y luego, cuando quisiera finalizar la sesión de alguien, revocaría el token de actualización al eliminarlo del servidor. Luego, después de una hora, el usuario se desconectaría y tendría que volver a iniciar sesión para recuperar el acceso.