Actualmente tengo una aplicación web monolítica heredada de 15 años con cerca de 1 millón de usuarios, utilizando un sistema de autorización y autenticación local: JAAS, nombres de usuario y pwds almacenados en una base de datos con hashing básico de contraseñas, algunas preguntas de verificación personal 2FA (con diferentes algoritmos de hashing, etc.
Revisaré la aplicación durante los próximos 12 a 18 meses, principalmente centrada en la interfaz de usuario, pero también actualizaré lentamente las partes subyacentes (actualización a Spring, Spring Security, etc.). Dentro de este proyecto, hemos decidido abordar la actualización de la interfaz de usuario módulo por módulo; haciendo que cada módulo esté disponible una vez que esté completo; Una oportunidad perfecta para dividir el monolito en aplicaciones web individuales (todas manteniendo el mismo diseño UX).
Donde estoy atascado tratando de planificar esto es en el nivel de autenticación y autorización. Necesito una solución transversal que abarque todos los módulos, de modo que cuando un usuario sea dirigido de una aplicación web a otra, sea una transición perfecta: ni siquiera sabrán que están en aplicaciones web diferentes. OAuth2 suena como la solución perfecta.
Estoy atrapado tratando de entender cómo integrar esto. ¿Tengo que construir mi propio servidor OAuth2 personalizado? Eso me golpea como una idea terrible. Pero como:
- migrar todas mis cuentas de usuario y proceso de autorización a un servidor OAuth2 de terceros
- personalizar el aspecto para que coincida con el resto de mi aplicación (no estoy seguro de cuán fácil / probable será)
- evitar la típica ventana emergente "Aplicación XYZ desea permiso para acceder a su cuenta ..." al conectarse a través de un servidor de terceros (Ej: Google OpenID, Facebook, etc.).
Mi objetivo es proporcionar una transición perfecta para el usuario del estado actual al nuevo, pero brindando la capacidad de crear aplicaciones web separadas que autentiquen y autoricen fuera de la aplicación web.
fuente
Respuestas:
Divulgación : soy ingeniero en Auth0 .
Depende de un punto importante ... debe decidir si:
Ambas opciones son perfectamente viables desde el punto de vista de sus requisitos funcionales. Con el desarrollo personalizado, tiene el control total de la funcionalidad que decide admitir, por lo que centraré parte de la respuesta en cómo Auth0 puede responder a los requisitos que enumeró .
Sin embargo, antes de pasar a eso, sin importar su decisión, para la autenticación debe centrarse en OpenID Connect en lugar de OAuth2. Esto último será más aplicable si planea tener también API en la mezcla y no solo dividir el monolito en aplicaciones web separadas.
¿Cómo migrar usuarios existentes a un sistema basado en Auth0?
Puede optar por seguir usando su base de datos y confiar en Auth0 para proporcionar todo el cumplimiento de los protocolos relacionados con la autenticación que necesite usar o puede migrar a sus usuarios a las bases de datos administradas por Auth0 y dejar de preocuparse por cómo almacena y valida las contraseñas.
Si prefiere seguir usando su base de datos, vea Autenticar usuarios con nombre de usuario y contraseña usando una base de datos personalizada
(Los documentos se refieren a MySQL solo como ejemplo, se admiten otros motores de base de datos)
Por otro lado, puede mover sin problemas las credenciales de usuario a las bases de datos Auth0 al aprovechar el proceso de migración descrito en Migrar usuarios a Auth0
También puede crear todos sus usuarios en Auth0 a través de la API de administración si prefiere que todos comiencen a usar nuestro algoritmo de hash de contraseña de una vez. Esto tiene el efecto secundario de requerir que los usuarios restablezcan su contraseña.
¿Cómo seguir usando la autenticación personalizada de dos pasos (preguntas de verificación)?
La canalización de autenticación proporcionada por Auth0 es totalmente personalizable mediante el uso de reglas . Esto significa que, aunque no tuvo que implementar ningún elemento relacionado con el protocolo, aún puede ajustar los pequeños detalles de cómo ocurre la autenticación en su aplicación.
Esto incluye la posibilidad de continuar usando sus preguntas de verificación existentes como una forma de realizar un proceso de autenticación de dos pasos en el que el usuario proporciona una contraseña inicial verificada por Auth0 y luego les solicita más información de una regla personalizada. (las reglas son solo Javascript, por lo que las posibilidades son infinitas)
Sin embargo, también puede decidir abandonar las preguntas de verificación y, en su lugar, utilizar Auth0 Guardian como una forma de aumentar la seguridad del proceso de autenticación.
¿Cómo personalizar el aspecto de la interfaz de usuario de autenticación?
Con Auth0, puede tener una interfaz de usuario de autenticación limpia en poco tiempo al aprovechar las páginas de inicio de sesión predeterminadas o los widgets de autenticación como Lock . Todo esto admite cierto grado de personalización y siempre puede decidir hacer su propia interfaz de usuario usted mismo y, en cambio, aprovechar las bibliotecas Auth0 de nivel inferior ( Auth0.js ) que no limitan la interfaz de usuario.
Para más información sobre personalización:
¿Cómo evitar páginas de consentimiento explícito?
Puede utilizar Auth0 como proveedor de identidad para fines de autenticación y también como servidor de autorización OAuth2 (actualmente disponible solo en la región de EE. UU.) Para sus API.
Como proveedor de identidad, no tiene que preocuparse por las páginas de consentimiento, el usuario se autentica con sus credenciales administradas por Auth0 y luego es redirigido a su aplicación, eso es todo.
En el escenario OAuth2 como servicio cuando el consentimiento está habilitado, la hoja de ruta incluye permitir omitir páginas de consentimiento para ciertas aplicaciones.
En una nota final, eso parece un proyecto muy interesante y desafiante que llegaste allí, así que la mejor de las suertes independientemente de tu decisión final.
Ya pasé por algo similar en un trabajo anterior cuando tuve que volver a implementar el sistema de autenticación de una aplicación heredada. Implementamos nuestro propio proveedor de identidad y servidor de autorización y, para ser sincero, todavía tengo la sensación de que hemos olvidado algo realmente esencial.
Creo que ese es el mayor problema con la implementación de su propia seguridad, habrá ocasiones en que los plazos impongan atajos y la seguridad no es realmente un buen área para hacer atajos.
Si tiene más preguntas, avíseme si cree que puedo ser útil.
fuente