¿Este esquema de autorización de token es seguro?

0

Tengo una aplicación web, llámela A, desde donde el usuario debería poder iniciar sesión en otra B (desarrollada por otra compañía) sin ingresar ningún nombre de usuario / contraseña.

Hemos pensado en el siguiente esquema:

  • Generamos un ID secreto aleatorio para cada usuario en la base de datos
  • La ID secreta se regenera después de iniciar sesión en A
  • Guardamos los nombres de usuario del sistema B en nuestro sistema para cada usuario
  • Cuando el usuario inicia sesión en A y desea abrir B, el sistema A envía el nombre de usuario y la ID secreta al sistema B a través de HTTPS, B, antes de responder a la solicitud, los envía a A, que verifica si la ID secreta es correcta, la regeneró y envía de vuelta a B si era correcto; B, si tiene una respuesta positiva, registra al usuario y envía el ID de la sesión a A

¿Este esquema tiene fallas?

    
pregunta Somnium 09.01.2017 - 11:27
fuente

1 respuesta

1

Parece que podría beneficiarse de un servidor de autorización independiente en el que todas sus aplicaciones pueden confiar.
A la larga, probablemente será más fácil hacer que la autenticación / autorización sea una problema transversal en lugar de copiar usuarios de en aplicación a otro.

OpenId Connect podría ser apropiado; se construye sobre OAuth2 .

Es posible que estas no sean las fallas que está buscando, pero considere estas situaciones separadas:

  • 3 nuevos sistemas C, D y E se introducen en la organización y los usuarios necesitan iniciar sesión en todos ellos
  • Surge un nuevo requisito para que el Sistema B llame a una API HTTP, Sistema F, como el usuario actual
  • Se elimina un usuario del Sistema A
  • El sistema A está desactivado, pero el sistema B se ha vuelto crítico para el negocio
  • Un usuario abre B directamente, sin pasar por A
  • Regenerar todas las claves secretas puede causar una carga innecesaria en la red / sistemas
  • La empresa consultora que desarrolla System B tiene que aprender su método de autenticación personalizado
  • Los nuevos miembros del equipo tienen que aprender el protocolo de autenticación propio en lugar de un estándar de la industria
  • Habiendo obtenido acceso al Sistema A, un atacante también obtiene acceso al Sistema B.

Lo que ha descrito no suena como una IMO basada en token. En la autenticación basada en token, el nombre de usuario y la contraseña se intercambian por un token, que se presentaría al Sistema A con cada solicitud.
En un nivel alto, así es como entiendo que funciona la autenticación basada en token:

  • El usuario no autenticado navega al Sistema A
  • El sistema A redirige el navegador de los usuarios a System Z, el proveedor de autenticación
  • El usuario ingresa sus credenciales en System Z
  • System Z redirige el navegador del usuario a System A, con un token
  • Todas las solicitudes posteriores del navegador del usuario al Sistema A incluyen el token
  • El sistema A confía en tokens emitidos por System Z

Tenga en cuenta que el usuario no ingresa sus credenciales en el Sistema A.

Los pasos anteriores están simplificados en exceso; no incluyen el vencimiento del token o tokens de actualización. He descrito el flujo de autorización OAuth2 más simple (flujo implícito); el más común es el "flujo de código de autorización".
El flujo implícito es adecuado para los clientes de JavaScript, mientras que el flujo del código de autorización es adecuado para las aplicaciones basadas en servidores. Hay mucha información buena en línea sobre OAuth2 y OpenID Connect.

    
respondido por el Bvrce 09.01.2017 - 16:17
fuente

Lea otras preguntas en las etiquetas