Implementación de punto de autenticación único

Estoy creando una serie de aplicaciones web conectadas a un único punto de autenticación. Básicamente, un usuario intenta acceder a un sitio, si no se autentica, se lo redirige a la página de inicio de sesión del sistema de autenticación central. Una vez que inician sesión correctamente, son redirigidos a su aplicación. A partir de ese momento, si acceden a cualquier otra aplicación, iniciarán sesión automáticamente.

Un par de detalles adicionales: 1) todas las aplicaciones se ejecutarán en el mismo dominio, por lo que puedo usar cookies de dominio, lo que facilita las cosas; 2) los usuarios pueden tener acceso a algunas aplicaciones y no a otras, por lo que debe tenerse en cuenta; 3) el usuario debe poder recuperar los permisos específicos de cada aplicación.

He implementado algo, pero no estoy 100% contento con eso. En este momento, esto es lo que tengo: 1) la aplicación web verifica la existencia de una sesión (específica de la aplicación) y una cookie que es un token JWT que se envió desde el sistema de autenticación centralizado; 2) si la cookie no existe, redirijo a la página de inicio de sesión en el sistema de autenticación; 3) una vez que el usuario inicia sesión, es redirigido a su aplicación pasando un token JWT; 4) la aplicación verifica el token a través de una llamada REST API al sistema de autenticación (hacer que estas llamadas REST API se basen en un token de acceso separado), si es válido, el token JWT se guarda como una cookie y se inicia una sesión con el usuario conectado; 5) si la sesión de la aplicación caduca, verifica si la cookie existe y si es así, la aplicación hace lo mismo que en el paso 4, verifica el token y reinicia la sesión; 6) al cerrar sesión, el sistema simplemente elimina la cookie, asegurar que el usuario haya cerrado la sesión de todas las aplicaciones; 7) si el token caduca, la aplicación usa el token caducado para solicitar uno nuevo, donde la firma del token y otros reclamos se validan antes de emitir uno nuevo, lo único que no se valida es el reclamo de vencimiento.

Para aclarar, se utiliza la existencia de una sesión específica de la aplicación para que no tenga que seguir haciendo llamadas REST API constantemente para verificar el token. Pero dado que el token se verificó una vez, ¿sería seguro usar esa cookie como indicador de que hay una sesión válida?

Una cosa de la que no estoy seguro es que mi token necesita tener algo que indique para qué aplicación es porque se pueden hacer otras llamadas a la API REST usando el token para obtener algunos recursos específicos de la aplicación. Pero si obtengo un token para app1 y luego inicio sesión en app2, app2 dependerá de la cookie generada por app2. Parece que me gustaría tener dos tokens, uno que se pueda almacenar como una cookie de dominio para indicar que el usuario está autenticado, y otro que en realidad sería específico de la aplicación y se puede usar para hacer llamadas a la API REST para otra aplicación. recursos específicos

¿Estoy complicando demasiado esto o mi línea de pensamiento coincide con lo que otros están viendo / haciendo? ¿O hay una forma más elegante de hacer esto? He pensado implementar algo como Open ID, pero parece un poco exagerado para nuestras necesidades. Quiero que esto sea lo más simple posible para poder documentar el proceso y que otros equipos de desarrolladores puedan desarrollar aplicaciones que se conecten al sistema de autenticación sin necesitar demasiada ayuda.

No te vuelvas loco. Nadie en su sano juicio intentaría escribir algo así desde cero. Usa OAuth. Puede usar la especificación de token JWT Bearer para el token y usar ámbitos para determinar a qué aplicación o recurso tiene acceso el usuario. ¡Esta no es una buena área para comenzar a reinventar la rueda!

Recientemente, acabo de seguir una guía aquí que explica el proceso de configuración para la autenticación basada en token. Una forma en que puedo imaginar pasar alguna forma de identificación específica de la aplicación sería mediante el uso de notificaciones.

Entonces tiene el sitio web A que lo redirige a la página de su sistema de inicio de sesión. El sitio web A también pasó algunos otros datos, como dónde llevar al usuario después de iniciar sesión y dónde está el sitio web A. Su sistema de autenticación analiza estos datos y, mediante un cambio de alguna forma, agrega un reclamo al token de los usuarios que identifica el alcance de su aplicación actual.

Además, para ayudar a combatir al usuario que cambia de aplicaciones muy rápido y aún tiene acceso a los recursos de la aplicación para la aplicación1 mientras está en la aplicación2, sus tokens de acceso caducan muy rápido. En mi sitio web de demostración en ejecución creado con la guía anterior, la mía caduca cada minuto, así como la implementación de un refresh_token hace que todo sea más fácil. Otro paso que podría ser útil es que al agregar reclamos a los usuarios también se agrega un rol a ese usuario que indica que está en un sitio web.

Luego, en app1's / api / endpoint / getData establezca [Authorize (Roles = "App1")], esto garantizará que solo access_tokens que contengan un rol = App1 pueda usar ese punto final y luego dentro de su javascript o cualquier lado del cliente que escriba su uso simplemente realice comprobaciones lógicas de errores, como no acceder a un punto final específico y tal vez el usuario necesite obtener un nuevo acceso_token utilizando el token de actualización, y así sucesivamente.

Usando la misma guía que mencioné anteriormente, siga ese enlace y busque esto:

identidad var = nueva ClaimsIdentity (context.Options.AuthenticationType);

Como puede ver, la identidad está agregando afirmaciones que son básicamente valores que se encapsularán dentro de access_token.

Ahora, cuando un usuario llama a su API web que tiene un atributo autorizado encima, simplemente verifica las afirmaciones de los usuarios.

Un ejemplo de esto se puede encontrar aquí .