Dónde almacenar el acceso y actualizar tokens en la aplicación web del cliente ASP.NET: llamar a una API REST

17

He creado una API web en ASP.NET que actúa como punto de entrada en una base de datos de SQL Server para los datos del informe. Este servicio tiene un punto final "token" que autentica a un usuario a través de la Identidad ASP y devuelve un acceso de 20 minutos y un token de actualización de 2 semanas.

Esta API solo debe ser accesible a través de nuestras propias aplicaciones y productos. Estaremos escribiendo una aplicación para Android, una aplicación para iOS y una aplicación web ASP.NET que se autenticará y obtendrá datos de esta API web descrita anteriormente. Seré responsable de la aplicación web del cliente ASP.NET y de la API. Estamos creando estas aplicaciones internamente para que nuestros clientes puedan iniciar sesión y usarlas. Ninguna tercera parte ajena a mi empresa llamará a nuestra API a través de ninguna de sus propias aplicaciones.

Para la aplicación web ASP.NET de mi cliente, la estoy escribiendo en ASP.NET MVC y en realidad no tiene una base de datos desde ahora, ya que se comunica con la API para todo.

Comencé con esto como una base, y funciona ... pero ahora necesito convertir este archivo HTML a una aplicación web ASP.NET en MVC y descubrir dónde y cómo almacenar el token de acceso y la actualización. tokens enlace /

Mis preguntas son:

  1. Entiendo que necesitaré pasar el token de acceso en llamadas posteriores a la API para realizar operaciones CRUD. ¿Dónde debería hacer mi solicitud web para autenticar al usuario en la aplicación web al iniciar sesión ... desde el código C # detrás o JavaScript como en el tutorial mencionado anteriormente? Lo pregunto porque me doy cuenta de que necesitaré el token de acceso en mis llamadas JS Ajax, pero he oído que el token de actualización debe ser más "seguro" y ¿Llamar desde el código del servidor podría darme opciones más seguras de hacerlo?

  2. ¿Dónde almaceno el token de acceso? ¿En una cookie creada en JavaScript o en el servidor? En el almacenamiento local de JavaScript? ¿En una variable de sesión que pueda pasar a JavaScript tal vez?

  3. ¿Dónde almaceno el token de actualización? Necesitaré esto para renovar el token de acceso antes de que caduque. Busqué en Google hasta la muerte, pero no puedo encontrar una buena solución ASP.NET en línea que me diga dónde o cómo almacenar esto desde la perspectiva de mi aplicación web consumidora. ¿Una cookie creada desde el servidor, guardada en una base de datos SQL que utiliza la aplicación web, en una variable de sesión?

Necesito ayuda desesperadamente, y esto me está volviendo loco y me mantiene despierto por la noche. Espero que alguien pueda proporcionar un ejemplo completo y simple y describir completamente lo que necesito hacer.

    
pregunta Andy DesRosiers 18.09.2015 - 19:09
fuente

1 respuesta

10

1. ¿Dónde autenticar al usuario?

Si es un usuario el que necesita autenticarse, entonces necesita algo en su interfaz de usuario. Desde su front-end, puede hacer un POST a su back-end, con las credenciales de usuario. Usted verifica las credenciales de usuario y emite un par de acceso / actualizar a token en caso de que se conozcan las credenciales. SIEMPRE tendrás que ir a través del back-end para autenticar a un usuario. Mencionas que el tutorial lo hace en JS, pero no lo hace. POSTS a un formulario de inicio de sesión. El POST se inicia en JS, pero va al back-end.

2. ¿Dónde guardo los accesstoken?

El acceso se puede almacenar de la misma manera que las cookies de autenticación normales. Tiene varias opciones (cookie segura de solo http, almacenamiento local, almacenamiento de sesión, etc.). En el escenario más simple, simplemente lo almacena en una cookie para que se envíe junto con cada solicitud. Sin embargo, para una aplicación móvil, probablemente sea más fácil almacenarla en LocalStorage.

3. ¿Dónde guardo la actualización?

Esto depende en gran medida de su aplicación. I hice la misma pregunta hace un tiempo, para las aplicaciones móviles (asegúrese de leer los comentarios también). Debe guardar el token de actualización en un lugar seguro. Para las aplicaciones que desarrollará, puede seguir las sugerencias de la respuesta a la que he vinculado, es decir:

  • Almacene el token de actualización en LocalStorage
  • Almacene el token de actualización cifrado en algún lugar del sistema de archivos, utilizando una API proporcionada por Android / IOS. Almacenar la clave de cifrado en localstorage. (O al revés).

Para otro tipo de aplicaciones, existen otras posibilidades. El almacenamiento tanto del acceso directo como del token de actualización en LocalStorage puede parecer incorrecto desde un punto de vista de seguridad, pero es probable que un atacante tenga más suerte en la intercepción del token cuando esté en tránsito, que el acceso al almacenamiento local. Otras sugerencias, a veces más exóticas, se dan aquí (por ejemplo, almacenamiento seguro de IOS).

Información adicional

  • Personalmente me gusta esta serie de blogposts mucho. Tenga en cuenta que pueden comenzar a volverse un poco anticuados, pero contienen una gran cantidad de información con respecto a una configuración REST-OWIN.
  • No olvide implementar todos los demás controles de seguridad, que no he mencionado, ya que esto nublaría la respuesta. Deben implementarse HTTPS, cookies de solo http, cookies seguras, prevención XSS, etc., o su token será robado mucho más rápido que el tiempo que necesita para leer esta respuesta.
respondido por el Michael 21.09.2015 - 20:59
fuente

Lea otras preguntas en las etiquetas