SSO initié par IdP vs SSO initié par SP
En savoir plus sur les différences entre le SSO initié par IdP et le SSO initié par SP et pourquoi le SSO initié par SP est plus sécurisé.
En savoir plus sur les différences entre le SSO initié par IdP et le SSO initié par SP et pourquoi le SSO initié par SP est plus sécurisé.
Comme son nom l'indique, le SSO initié par SP est lancé par le fournisseur de service. L'utilisateur commence le processus d'authentification en accédant à une ressource sur le site web du SP. Le SP redirige ensuite l'utilisateur vers l'IdP pour l'authentification. Une fois que l'utilisateur est authentifié, l'IdP génère un jeton (OIDC) ou une assertion SAML (SAML) et l'envoie au SP. Le SP valide le jeton ou l'assertion et accorde l'accès à l'utilisateur.
Contrairement au SSO initié par SP, le SSO initié par IdP est lancé par le fournisseur d'identité. L'utilisateur commence le processus d'authentification depuis le site web de l'IdP. Normalement, l'utilisateur trouve une liste d'applications SP prises en charge sur le portail de l'IdP. L'utilisateur clique sur l'application SP et est redirigé vers le site web du SP avec une identité pré-authentifiée.

Le SSO initié par IdP est plus adopté par les grandes entreprises et organisations qui dépendent de diverses applications ou services tiers. Comme Workday, Salesforce, etc. Il offre un moyen centralisé de gérer l'accès des utilisateurs à plusieurs applications et d'appliquer des authentifications SSO. En activant le SSO initié par IdP, les employés peuvent accéder directement aux applications connectées depuis le portail de l'IdP sans avoir à visiter chaque site web d'application. Cela réduit le temps d'intégration et améliore l'expérience utilisateur.
Le SSO initié par IdP présente plus de risques que le SSO initié par SP.
Absence de contexte d'authentification : Toutes les requêtes d'authentification initiées depuis l'IdP sont non sollicitées. Ainsi, le SP initie le processus d'authentification, ouvrant potentiellement la porte à un accès non autorisé. Il existe un risque que la session de l'utilisateur soit détournée. Un acteur malveillant pourrait initier le processus de connexion pour un utilisateur légitime sans sa connaissance ou son consentement.
Fixation de session : Comme le SP ne lance pas le processus d'authentification, la session de l'utilisateur pourrait être fixée à la session de l'IdP. Cela pourrait conduire à des attaques de fixation de session où un attaquant pourrait fixer la session de l'utilisateur à celle de l'IdP et accéder de manière non autorisée au compte de l'utilisateur.
Attaques de phishing : Le SSO initié par IdP pourrait être vulnérable aux attaques de phishing. Un acteur malveillant pourrait tromper l'utilisateur pour qu'il visite un faux portail de l'IdP et voler les identifiants de l'utilisateur. Une fois que l'utilisateur est connecté, l'attaquant pourrait rediriger l'utilisateur vers le SP avec une identité pré-authentifiée.
Aucune assurance sur la validation de la demande : Dans un SSO initié par SP, normalement le SP inclura les informations de sécurité nécessaires dans la demande à l'IdP pour maintenir l'intégrité de la requête. Une fois que le SP reçoit la réponse d'authentification, il validera ces informations pour prévenir toute attaque CSRF. Par exemple, le paramètre state dans OIDC et RelayState dans SAML. Cependant, dans le SSO initié par IdP, le SP ne lance pas le processus d'authentification, donc le SP n'a aucune assurance sur la validation de la demande.
Le SSO initié par IdP n'est pas pris en charge par OIDC en raison des vulnérabilités ci-dessus. OIDC exige que le SP initie le processus d'authentification pour assurer l'intégrité de la demande. Même dans les cas où les utilisateurs commencent le processus d'authentification à partir d'un tiers qui n'est pas le SP, l'utilisateur doit d'abord être dirigé vers le SP pour initier le processus d'authentification.
Mais dans SAML, le SSO initié par IdP est possible. L'IdP peut générer une assertion SAML sans que le SP initie le processus d'authentification. Dans un SAML initié par IdP, une assertion SAML sans RequestID et RelayState appropriés pourrait être envoyée directement à l'URL ACS du SP. Le SP devrait être capable de gérer ce type d'assertion et d'accorder l'accès à l'utilisateur. (Remarque : Sans le RequestID et le RelayState, le SP n'a aucune assurance sur l'intégrité de la demande).
Bien que le SSO initié par IdP offre un moyen centralisé de gérer l'accès des utilisateurs à plusieurs applications, il présente plus de risques que le SSO initié par SP. Le SSO initié par SP est plus sécurisé et offre plus d'assurance sur l'intégrité de la demande d'authentification. Il est recommandé d'utiliser le SSO initié par SP pour les SSO basés sur OIDC et SAML.