SSO initié par IdP vs SSO initié par SP

Terminologie#

• Fournisseur d'identité (IdP) : Le service qui stocke et authentifie les identités des utilisateurs.
• Fournisseur de service (SP) : Un site web ou service qui fournit des services aux utilisateurs.
• Single Sign-On (SSO) : Un service de session et d’authentification des utilisateurs qui permet à un utilisateur d’utiliser un ensemble d’identifiants de connexion (par exemple, nom et mot de passe) pour accéder à plusieurs applications.
• SAML : Security Assertion Markup Language est une norme ouverte pour échanger des données d'authentification et d'autorisation entre les parties, en particulier entre un fournisseur d'identité et un fournisseur de service. C'est un protocole couramment utilisé pour le SSO. Une fois qu'un utilisateur est authentifié avec succès par l'IdP, l'IdP envoie une assertion SAML au SP, que le SP valide et accorde l'accès à l'utilisateur.
• OIDC : OpenID Connect est un protocole plus moderne et sécurisé pour le SSO. Il est construit sur OAuth 2.0 et fournit un moyen de vérifier l'identité de l'utilisateur en se basant sur l'authentification effectuée par l'IdP. Une fois qu'un utilisateur est authentifié avec succès par l'IdP, l'IdP envoie un jeton au format JWT au SP, que le SP valide et accorde l'accès à l'utilisateur.

SSO initié par SP#

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.

1. L'utilisateur visite le site web du SP et essaie d'accéder à une ressource.
2. L'utilisateur clique sur le bouton de connexion du fournisseur SSO (par exemple, Google, Azure AD, Okta, etc.).
3. Le SP redirige l'utilisateur vers l'IdP pour l'authentification.
4. L'utilisateur se connecte à l'IdP.
5. L'IdP envoie un jeton ou une assertion au SP.
6. Le SP valide le jeton ou l'assertion et accorde l'accès à l'utilisateur.

SSO initié par IdP#

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.

1. L'utilisateur se connecte à l'IdP.
2. L'utilisateur visite le portail de l'IdP et sélectionne une application SP.
3. L'IdP valide la session actuelle de l'utilisateur et redirige l'utilisateur vers le SP avec une identité SSO pré-authentifiée.
4. Le SP valide l'identité SSO et accorde l'accès à l'utilisateur.

SSO initié par IdP vs SSO initié par SP#

Avantages du SSO initié par IdP par rapport au SSO initié par SP#

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.

Risques du SSO initié par IdP par rapport au SSO initié par SP#

Le SSO initié par IdP présente plus de risques que le SSO initié par SP.

1. 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.

2. 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.

3. 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.

4. 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.

Limitations du SSO initié par IdP par rapport au SSO initié par SP#

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).

Conclusion#

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.