Autenticación para SPA

Question

Autenticación para SPA

#1 de João Angelo (11 votos)

10

Estoy desarrollando una aplicación para mi empresa con los siguientes parámetros & componentes:

1st Party Frontend Single-Page Application (SPA). Esto se implementa en TypeScript (un dialecto de JavaScript), y estamos desarrollando el código de forma interna.
API REST de backend de 1st Party que da acceso a un MongoDB ubicado en otro lugar. Esto se implementa en JavaScript y utiliza Express que se ejecuta en el nodo. Estamos desarrollando el código en casa. En este momento, todo lo que esta pieza está haciendo es proporcionar operaciones CRUD sobre una API REST.
Estas aplicaciones solo estarán disponibles para nuestros empleados . Todos los empleados tienen computadoras portátiles con Windows 10 que se han unido a Azure AD de nuestra compañía.
No tenemos un servidor de ADFS en las instalaciones. Somos 100% de nube.
La aplicación utilizará los recursos de Azure en su lógica empresarial, como Graph API.
La aplicación también utilizará otros recursos de terceros, como Dropbox de nuestra empresa.
La autenticación en "la aplicación" también debe autenticarse en todas las demás aplicaciones de terceros (como Dropbox) de la mejor manera posible.
Hoy tenemos 10s de empleados. Es muy poco probable que tengamos más de 50 empleados en los próximos dos años, cuando esta aplicación vaya a la versión 2 y contrataré a alguien para construirla.

Ha llegado el momento de implementar la autenticación y autorización para nuestra aplicación. La aplicación debe autenticar y autorizar contra Azure AD. El escenario ideal es que un usuario conectado a la computadora portátil de la empresa debe autenticarse de forma automática en la aplicación, y que los usuarios de otra máquina (piense en el aeropuerto o en el quiosco del hotel) iniciarán sesión con sus credenciales de Azure AD .

Mi pregunta es en torno a qué flujo de concesión OAuth2 se debe usar en este escenario.

He leído una serie de artículos de Microsoft y OAuth, he leído varias clases de Udemy, etc. y he recibido consejos contradictorios de estas fuentes. Algunos sugieren que los SPA deben usar una concesión implícita, mientras que otros dicen que si hay lógica de negocios en un servidor backend (y hay / habrá), se debe usar una concesión de credenciales de cliente.

Soy un desarrollador con mucha experiencia, pero no soy un experto en seguridad. En mi mundo perfecto, externalizaría el diseño y la implementación de la pieza de autenticación de esta aplicación a alguien que sea un experto en seguridad, pero el presupuesto es una restricción importante aquí. Simplemente no es posible gastar miles de USD para que alguien nos construya esto en esta etapa.

Dicho todo esto, teniendo en cuenta el diseño y la arquitectura descritos anteriormente, ¿cómo se debe implementar la autenticación? ¿Qué flujo de subvención debería utilizarse?

authentication oauth

pregunta John Dibling 20.12.2016 - 16:57

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication oauth

Riesgos de seguridad de HomeX Brew OSX Verificar el inicio de sesión y el cifrado con PBKDF2

score 11 · Accepted Answer

TL; DR Vaya con implícito ... Consulte ¿Qué flujo de OAuth 2.0 debo usar? para una visualización del proceso de decisión.

Cuando se trata de autenticación, el diablo está en los detalles ... Intentaré no olvidar ninguno.

La especificación de OAuth2 base introdujo cuatro tipos de concesión:

subvención implícita
concesión de código de autorización
concesión de credenciales de cliente
concesión de credenciales de contraseña de propietario de recurso (ROPC)

Si excluye ROPC que se incluyó para proporcionar una ruta de migración sin problemas para las aplicaciones que usaban para almacenar el nombre de usuario y la contraseña para poder actuar en nombre del usuario, le quedan tres posibles subvenciones.

Entre estos tres, hace una clara distinción entre la concesión de credenciales de cliente (CC) y las otras dos. La subvención CC está dirigida a las aplicaciones cliente que desean acceder a los recursos por sí mismos, es decir, con la identidad de la aplicación cliente en sí.

Esto implica que para poder utilizar esta concesión, una aplicación cliente debe poder realizar la autenticación del cliente para probar que la solicitud proviene de la aplicación legítima.

Un SPA no puede realizar la autenticación del cliente porque cualquier clave secreta que almacene en la aplicación como un medio para autenticar sería visible para cualquier persona que quisiera ver el código fuente. La concesión de CC se restringe principalmente a las aplicaciones del lado del servidor donde es más fácil mantener un secreto.

Otro punto importante es que si desea que su aplicación cliente acceda a los recursos que son propiedad de un usuario final y / o realice acciones en su nombre, la subvención CC no es aplicable.

Parece que el grupo de opciones es ahora la mitad de lo que empezamos y los candidatos restantes son la concesión implícita o del código de autorización. En general, si tiene un SPA , el código que realiza las solicitudes que requieren autenticación / autorización está en el lado del navegador, por lo que la opción obvia sería la concesión implícita porque entrega el tokens como parte de la respuesta del punto final de autorización y no requiere una solicitud adicional al punto final del token que en el navegador-land podría significar una solicitud CORS que podría o no ser viable.

Como nota adicional, si los componentes que describió (Front-end SPA y Back-end API) se ven como una sola aplicación que vive bajo el mismo dominio, sin planes de abrir la API a otras aplicaciones, incluso debería es posible confiar en la autenticación tradicional basada en cookies solo en HTTP que se iniciaría con un token de ID recibido de acuerdo con las reglas de OpenID Connect. Usted mencionó REST, por lo que solo desea hacer una advertencia de que la autenticación basada en cookies no implica necesariamente una sesión administrada del lado del servidor; sin embargo, la autenticación basada en cookies requeriría mitigaciones de CSRF.