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.