La función principal de IdP es "autenticar" la identidad reclamada por el usuario, y garantizar al SP que la identidad del usuario haya sido verificada.
Para esto, (más comúnmente), la contraseña debe ser verificada por el IdP y, por lo tanto, se almacena con el IdP.
En un sistema implementado correctamente, el SP nunca debe estar en posición de "acceder" a la contraseña y / o cualquier otro mecanismo utilizado para verificar la identidad del usuario. Por lo tanto, nunca se almacena con el SP.
Cómo funciona:
Normalmente, el IdP le proporciona al usuario un token verificable que indica a un SP que la autenticación se ha realizado correctamente. El usuario pasa esto al SP como "prueba de autenticación exitosa". No hace falta decir que el SP no toma la palabra del usuario para ello. Así que el SP verifica este token con el IdP y solo después de confirmar que el token es válido, continúa con el siguiente paso (generalmente el paso de autorización).
En caso de compromiso del IdP:
Sí, un compromiso en el lado del IdP tiene un mayor impacto. Sin embargo, el IdP no necesita conocer todas las credenciales necesarias para acceder a la aplicación del SP. Por lo tanto, una aplicación SP cuidadosamente diseñada usaría al menos un atributo del usuario; y no usar solo el token para abrir el acceso. El IdP no conocería ese atributo y, por lo tanto, no podría acceder a la aplicación SP, haciéndose pasar por un usuario. Con suerte, esto no está sobre-diseñado para el nivel de autenticación.
Sin embargo, debo confesar que no lo he visto en la práctica. La mayoría de los SP están agradecidos solo por hacer que la integración de IdP funcione lo suficientemente bien y dejarlo así. :)
sugiere que la contraseña se almacene en el IdP (talentlms).