Autenticación segura en la aplicación SPA / Javascript con soporte "recordarme"

0

Tengo 3 proyectos de sitio web de la siguiente manera;

  1. identity.example.com (asp.netcore + IdentityServer4)
  2. api.example.com (asp.netcore webapi)
  3. www.example.com (asp.netcore + aurelia)

Puedo autenticar al usuario utilizando el agente de usuario de SPA usando un tipo de concesión implícito y almaceno el access_token en localStorage. Debido a que localStorage no es seguro, el acceso o el uso de larga duración o el uso de refresh_token no es seguro, por lo tanto, mis usuarios tendrán que iniciar sesión cada X minutos, lo que no es aceptable como usted estaría de acuerdo.

Mi objetivo es que los usuarios tengan la opción de "recordarme" y que mantengan las cosas tan seguras como aceptables (sé que no hay seguridad al 100% en este sentido)

Creo que tengo las siguientes opciones;

1. Proxy completo entre SPA y API / IdentityServer, todo lo almacenado como http_only cookie

  • spa publica las credenciales en su propio backend (www.example.com/login)
  • el backend del spa obtiene access_token y refresh_token de identity.example.com, almacena los tokens en la cookie http_only o en la sesión.
  • el backend del spa actúa como un proxy entre la api y el spa y el spa realiza las llamadas a su propio backend, no a la api
  • el backend del spa enruta todas las solicitudes de API a api.example.com usando el access_token almacenado en la cookie / sesión y devuelve el resultado al usuario_agente.

Ahora, este enfoque parece seguro, pero agrega un nivel de proxy que tendría un efecto negativo en el rendimiento, los tiempos de respuesta de las solicitudes, etc. Además, necesitaría escribir una envoltura / proxy para cada método de API en el backend del spa (el proxy ) Eso haría llamadas a los métodos de api reales, lo que no es tan bueno.

Pensé en el siguiente flujo para hacerlo seguro y no doloroso para el usuario al mismo tiempo;

2. Semi Proxy entre SPA e Identity Server (solo para actualizar tokens)

Resumen: el SPA tiene acceso a access_token. Sin embargo, para actualizar el token, el spa debe interactuar con su backend, que mantiene de forma segura el refresh_token en la sesión / cookie.

  • spa publica las credenciales en su propio backend (www.example.com/login)
  • spa obtiene un código de autorización del servidor de identidad (client_secret no es necesario para esto) y lo publica en su propio backend
  • el backend del spa obtiene access_token y refresh_token de identity.example.com usando el código de autorización, almacena los tokens en la cookie http_only o en la sesión y también incluye access_token en el cuerpo de respuesta
  • el spa almacena el access_token en su almacenamiento local, y lo usa para llamadas directamente a la api (api.example.com, sin proxy)
  • cuando caduque el access_token, el usuario-agente (spa) le pide a su propio backend que actualice el access_token en nombre de sí mismo
  • el backend del spa recupera el nuevo access_token y refresh_token del servidor de identidad. Actualiza los tokens en la sesión / cookie y devuelve access_token al user_agent (spa)
  • user_agent (spa) actualiza el access_token en su localStorage y lo usa para futuras llamadas a la api.

    Ahora, las preguntas ... ¿Es el último flujo que he descrito seguro y aceptable según las normas? ¿Conoces un ejemplo de implementación de la misma? ¿O tienes otras sugerencias que debo seguir? Tal vez fallas de seguridad que debería considerar?

pregunta Hasan 02.04.2017 - 08:01
fuente

1 respuesta

0

Solo me pregunto si todos los proyectos deben estar separados ya que se ejecutan en el mismo alojamiento. Si elimina el Servidor de Identidad y combina la API y Aurelia en un solo proyecto con un único proveedor de autenticación bien conocido, puede usar la Identidad de Microsoft para autenticar y autorizar el SPA usando la página de Inicio del sitio web (con algunas páginas de Scaffolding of Razor). La configuración predeterminada utiliza SQL Server Express y una simple migración genera todas las tablas de Identidad. Por lo tanto, la API solo es necesaria cuando el usuario ha iniciado sesión, por lo que no es necesario utilizar tokens ni la horrible estructura necesaria para mantener un servidor de identidades de token para generar un inicio de sesión único complejo, ya que la identidad se mantiene fuera de la caja (Net Core 2.1 )

    
respondido por el Lance Parkington 06.11.2018 - 18:01
fuente

Lea otras preguntas en las etiquetas