REST API de seguridad Token almacenado vs JWT vs OAuth

92

Todavía estoy tratando de encontrar la mejor solución de seguridad para proteger la API REST, porque la cantidad de aplicaciones móviles y la API aumentan cada día.

He intentado diferentes formas de autenticación, pero todavía tengo algunos malentendidos, así que necesito el consejo de alguien más experimentado.

Déjame decirte, cómo entiendo todo esto. Si entiendo algo incorrectamente, por favor hágamelo saber.

En cuanto a que la API REST no tiene estado, así como WEB en general, debemos enviar algunos datos de autenticación en cada solicitud (cookies, token ...). Conozco tres mecanismos ampliamente utilizados para autenticar usuarios

  1. Token con HTTPS. He usado este enfoque muchas veces, es lo suficientemente bueno con HTTPS. Si el usuario proporciona la contraseña y el inicio de sesión correctos, recibirá un token en respuesta y lo utilizará para las solicitudes posteriores. La señal es generada por el servidor y almacenada, por ejemplo, en la tabla separada o la misma donde se almacena la información del usuario. Entonces, para cada servidor de solicitudes, se comprueba si el usuario tiene token y es el mismo que en la base de datos. Todo es bastante sencillo.

  2. Token JWT. Este token es auto-descriptivo, contiene toda la información necesaria sobre el token, el usuario no puede cambiar, por ejemplo, la fecha de vencimiento o cualquier otra reclamación, ya que el token es generado (firmado) por el servidor con una palabra clave secreta. Esto también está claro. Pero un gran problema, personalmente para mí, cómo invalidar el token.

  3. OAuth 2. No entiendo por qué este enfoque debería usarse cuando la comunicación se establece directamente entre el servidor y el cliente. Según tengo entendido, el servidor OAuth se usa para emitir token con alcance restringido para permitir que otras aplicaciones accedan a la información del usuario sin almacenar la contraseña y el inicio de sesión. Esta es una gran solución para las redes sociales, cuando el usuario desea registrarse en alguna página, el servidor puede solicitar permisos para obtener información del usuario, por ejemplo, de Twitter o Facebook, y rellenar los campos de registro con datos del usuario y así sucesivamente.

Considere el cliente móvil para la tienda en línea.

¿La primera pregunta debería preferir JWT sobre el token de primer tipo? Por lo que necesito un usuario de inicio de sesión / cierre de sesión en el cliente móvil, necesito almacenar un token en algún lugar o, en caso de JWT, el token debe ser invalidado al cerrar la sesión. Se utilizan diferentes enfoques para invalidar el token. Uno de ellos es crear una lista de token no válida (lista negra). Hmm La tabla / archivo tendrá un tamaño mucho mayor que si el token se almacenara en la tabla y estuviera asociado con el usuario, y se eliminara al cerrar la sesión.

Entonces, ¿cuáles son los beneficios del token JWT?

Segunda pregunta sobre OAuth, ¿debo usarla en caso de comunicación directa con mi servidor? ¿Cuál es el propósito de una capa más entre el cliente y el servidor solo para emitir el token, pero la comunicación no será con un servidor real sino con el servidor principal? Según tengo entendido, el servidor OAuth es responsable solo de otorgar permisos (tokens) a aplicaciones de terceros para acceder a la información privada del usuario. Pero mi aplicación de cliente móvil no es de terceros.

    
pregunta CROSP 04.10.2015 - 21:22

3 respuestas

77

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.
respondido por el Chad Clark 26.01.2016 - 21:07
4

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.

    
respondido por el Cerad 05.10.2015 - 16:43
3

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.

    
respondido por el RibaldEddie 05.10.2015 - 01:40

Lea otras preguntas en las etiquetas

Comentarios Recientes

Token de acceso JWT Token de acceso HTTP Registro de depuración de autenticación básica No mostrar el retraso de los tokens desde la última vez (horas) El canal de YouTube siempre mostrará videos en YouTube durante 12 horas (meses) Fuente para la adquisición fácil de Wallaroo encontrar un sitio de comercio electrónico, del cual es probable que tenga éxito, según los datos, buscar en el historial del sitio web de la tienda sería un gran desafío Perfer mostrando anuncios de vlog solo Amazon Keyword Team es... Lee mas