¿Cuáles son las mejores prácticas para la seguridad (basada en token) en una aplicación web?

4

Estoy diseñando una aplicación web que usa Spring MVC con controladores REST y páginas Angular JS que se comunican con estos controladores REST.

He implementado un mecanismo de seguridad / autorización basado en token que funciona. (Este se basa en la seguridad basada en token de JHipster).

Este token tiene un tiempo de caducidad (en este momento son 30 minutos, el valor predeterminado).

Me preguntaba cuáles son las mejores prácticas para hacer que esta aplicación web sea lo más segura posible y al mismo tiempo mantenga la facilidad de uso para el usuario.

En este momento, si un usuario (re) carga la página, el token en la cookie se comprueba si aún es válido. Si es así, entonces el token se renovará (de modo que se genere un nuevo token válido para --time--).

Si un usuario no visita la página por más de --tiempo-- y vuelve después, se desconectará porque su token ya no es válido.

¿Cuál es la mejor práctica para mantener al usuario conectado durante el mayor tiempo posible y al mismo tiempo mantener todo seguro?

Además, si el usuario estaría inactivo durante, digamos 30 minutos (en mi caso, la validez del token), y NO recarga la página y luego realiza una acción (que hace una llamada REST bajo el capó) no se autorizará (habrá un error 401 que indica que la seguridad está funcionando). ¿Sería una buena idea monitorear la validez en segundo plano con javascript y si el token está casi caducado, pedir una contraseña y renovar el token o incluso cerrar la sesión del usuario? La única solución tal como está ahora sería volver a cargar la página e iniciar sesión nuevamente ...

¡Cualquier información sobre cuáles son las mejores prácticas será muy apreciada!

    
pregunta E. V. d. B. 14.05.2015 - 20:07
fuente

1 respuesta

3

Hasta cierto punto, puede depender del diseño de su aplicación web y del nivel de seguridad Su aplicación requiere (basado en una evaluación de riesgos). En definitiva, no hay una sola respuesta. Apto para todas las situaciones. La clave para una buena experiencia de usuario es asegurar su El nivel de seguridad está en línea con los requisitos reales. Seguridad demasiado estricta los requisitos con un tiempo de espera demasiado corto conducirán a la frustración del usuario y también poco los expondrá a un riesgo excesivo.

Comprender cómo se usa tu aplicación es muy importante. Nada frustra a un usuario más que verse obligados a volver a autenticarse varias veces en lo que consideran una sesión única. Por ejemplo, tengo algunas aplicaciones que mantengo abiertas durante mucho tiempo, pero Puede que solo use la aplicación activamente unas cuantas veces al día. No quiero volver a autenticarme después de cada 30 minutos de tiempo de inactividad, pero me complace volver a autenticarme una vez día. Otras aplicaciones, como mi aplicación de banca, quiero que vuelva a autenticarme si La sesión ha estado inactiva por un corto período de tiempo.

Creo que el objetivo más importante es realizar el proceso de autenticación como Sin dolor como sea posible. Obligando a alguien a volver a ingresar sus credenciales y luego enviando Volver a la página de inicio rara vez es una buena solución. Lo que quieres es un proceso. que interrumpe brevemente el flujo de trabajo de los usuarios, pero una vez que se vuelve a autenticar, los pone volver a su flujo de trabajo en el punto en que fue interrumpido por la autenticación proceso.

Esto puede ser un poco complicado con las aplicaciones basadas tradicionales donde gran parte de la El estado del flujo de trabajo se mantiene en el servidor, especialmente si utiliza la sesión tiempos de espera Sin embargo, parece que su aplicación está usando muchos javascript y así que sospecho que mantienes un estado local.

Una solución es que su API de descanso verifique su token / sesión y si se toma una decisión hecho que necesita volver a autenticarse, devolver los datos json que esencialmente le dice a su aplicación para volver a autenticarse y luego volver a enviar la solicitud. Javascript en tu el cliente puede utilizar esta información para abrir una ventana modal para recopilar datos de autenticación, envíelos a su servicio de autenticación para obtener un nuevo token y luego vuelva a enviar la solicitud original con el nuevo token.

para una aplicación más tradicional, la solución general es usar el servidor redirecciones Cuando intenta acceder a una API REST y su token ha caducado, redirija el Vaya a la página de inicio de sesión, pero haga que la página de inicio de sesión también acepte una URL "siguiente". Una vez el el usuario está autenticado, el servicio de inicio de sesión usará el siguiente parámetro para redirigir el navegador de nuevo a la llamada API REST original. El desafío con esto puede ser asegurar usted mantiene toda la información estatal necesaria.

Otra adición que a veces es aceptable es tener su servicio de autenticación configurado de modo que si recibe una solicitud de autenticación que incluye un token que sigue siendo válido, no requiere que el usuario vuelva a autenticarse. En su lugar, simplemente emite un nuevo token. Esto permitirá que su aplicación renueve el token sin usuario interacción en el fondo. Sus API REST pueden configurarse para redirigir a la Servicio de autenticación si el token va a caducar en la próxima X segundos / minutos La ventaja de hacer esto es que si alguien tiene una sesión, no están obligados a volver a ingresar sus credenciales simplemente porque el valor que configuraste para la expiración del token ha caducado.

La mayoría de las veces, las aplicaciones en las que trabajo no tienen alta seguridad requisitos Para estas aplicaciones, tiendo a usar un valor de vencimiento largo para el tokens y un tiempo de espera de expiración de sesión razonable basado en el tiempo de inactividad. De esta manera, el el usuario no está obligado a volver a autenticarse simplemente debido a un tiempo de caducidad arbitrario para el token de autenticación, pero se requiere que se vuelvan a autenticar si la sesión ha estado inactivo durante un período de tiempo especificado.

    
respondido por el Tim X 22.05.2015 - 01:06
fuente

Lea otras preguntas en las etiquetas