SAML, OAuth2, OpenID : quel standard pour quelle utilisation ?

Avec la multiplication des fournisseurs de solutions et d’infrastructures cloud, il devient de plus en plus complexe de s’y retrouver lorsque l’on parle d’identité et d’authentification. Il faut être en mesure de proposer un moyen d’accéder aux différentes ressources de l’entreprise sans que les collaborateurs ne soient impactés par cela. On parle ici de problématiques de productivité mais également de sécurité. En effet, qui dit multiplication des services dit bien souvent multiplication des moyens d’accès. Même si la problématique de l’authentification unique n’est pas nouvelle, il s’avère que celle-ci a quelque peu évolué pour la raison évoquée au début de cette introduction. Par conséquent, revoyons (ou découvrons) ensemble les principaux standards utilisés dans ce cadre, ainsi que leurs spécificités.

SAML

Le SAML (pour Security Assertion Markup Language) est un standard ouvert, basé sur XML et développé par OASIS (consortium international œuvrant pour la standardisation de formats de fichiers ouverts). Il définit le processus permettant à un utilisateur d’accéder à plusieurs applications via une authentification unique (Single Sign-On ou SSO).

En termes de vocabulaire, nous allons retrouver ici :

• Un fournisseur de service : l’application cible.
• Un fournisseur d’identité : il s’agit de la brique d’infrastructure sur laquelle nous allons déporter l’authentification de l’utilisateur.
• Un client web (celui de l’utilisateur).

Pour ce qui est du fonctionnement, un exemple sera plus parlant qu’une longue explication :

1. Un utilisateur veut se connecter à une application de son entreprise à partir de son navigateur web.
2. L’application demande au navigateur web une authentification de type SAML.
3. Le navigateur va alors rediriger l’utilisateur vers le fournisseur d’identité qui va analyser la demande. Si l’utilisateur n’est pas authentifié, il devra saisir son identifiant et son mot de passe. Dès que celui est identifié et authentifié, le fournisseur d’identité va générer une réponse SAML qui prouvera son identité (le fichier XML présenté plus haut, appelé aussi « token » ou « jeton » en français).
4. Le fournisseur d’identité envoie le jeton au navigateur web.
5. Le navigateur redirige le jeton vers l’application.
6. Si la vérification réussit, l’utilisateur est connecté à l’application.

Globalement, le SAML est déjà bien implanté en entreprise de par son efficacité et son ancienneté. Il reste cependant assez lourd et contraignant (cela en raison de l’utilisation du XML) comparé à OpenID Connect que nous verrons dans les lignes qui suivent. Toutefois, si une organisation a déjà une partie de ses infrastructures utilisant SAML, il n’est pas forcément intéressant de partir sur d’autres technologies : le retour sur investissement ne serait que trop faible, voire nul.

OAuth2

La principale confusion régnant autour d’OAuth est qu’il est très souvent associé à SAML. Cependant, ces deux standards n’ont pas du tout la même utilité : de fait, là où SAML est un standard de fédération d’identité, OAuth est un standard de délégation d’autorisation. Pour être plus précis, OAuth, dans sa version 2, est un standard ouvert basé sur JWT (JSON Web Token, standard permettant l’échange sécurisé de jetons grâce à une vérification de l’intégrité des données) permettant à des services d’accéder à des données d’autres services via une autorisation du propriétaire de celles-ci et sans communication de mot de passe.

Concernant le vocabulaire utilisé, celui-ci diffère légèrement du SAML. Nous allons donc avoir :

• Un propriétaire d’une ressource (généralement l’utilisateur),
• Un client (l’application demandant l’accès à une ressource),
• Un serveur de ressource (serveur hébergeant une ressource, souvent le serveur d’autorisation),
• Un serveur d’autorisation (serveur distribuant les autorisations d’accès aux ressources).

Là encore, prenons un exemple. Un utilisateur souhaite importer des données d’une application B dans une application A. La problématique qui se pose est la suivante : comment faire en sorte que l’application A accède aux données de l’utilisateur stockées dans l’application B, sans que celui-ci ne communique son identifiant et son mot de passe :

1. L’utilisateur va demander à l’application A de contacter l’application B.
2. Il est redirigé par l’application A vers l’application B et il s’authentifie sur cette dernière.
3. L’application B va alors demander à l’utilisateur s’il autorise ou non l’application A à accéder aux ressources hébergées dans l’application B. Si l’utilisateur l’autorise, l’application B va envoyer un code d’autorisation au navigateur web de l’utilisateur.
4. Ce code est ensuite communiqué à l’application A.
5. Dès lors, le code est envoyé de l’application A vers la B pour obtenir en échange un jeton d’accès. Ce jeton a pour objectif d’éviter de communiquer les codes d’accès de l’utilisateur de l’application B à l’application A. On gagne ainsi en sécurité et en simplicité.
6. Le jeton d’accès est transmis à l’application A.
7. L’application A peut ainsi demander, via le jeton d’accès, d’accéder aux données de l’application B.

En conclusion à cela, nous pouvons ajouter qu’OAuth2 est donc un très bon outil pour sécuriser l’accès aux API d’une entreprise, mais en aucun cas un standard de fédération d’identité.

OpenID Connect

OpenID Connect est une couche d’identité au-dessus du protocole OAuth 2.0, permettant, à l’instar de SAML, de réaliser une authentification fédérée. Là où OAuth se base sur un principe de délégation d’autorisation, OpenID Connect se base sur un principe de fédération d’authentification. Pour le fonctionnement, on retrouve en grande partie les mécanismes d’OAuth. La différence principale réside dans la demande de jeton d’accès. Là où OAuth 2.0 va communiquer un jeton d’accès pour accéder aux données, OpenID Connect va communiquer un jeton d’identité pour accéder aux applications.

1. L’utilisateur veut se connecter à l’application.
2. Il est redirigé par celle-ci vers le serveur d’authentification, puis il s’authentifie.
3. Le serveur d’authentification va envoyer un code d’autorisation au navigateur web de l’utilisateur.
4. Ce code est communiqué à l’application.
5. Le code est envoyé de l’application vers le serveur d’authentification pour obtenir en échange un jeton d’identité (jeton au format JWT).
6. Le jeton d’identité est transmis à l’application. Celle-ci a donc la garantie de la part du serveur d’authentification que l’utilisateur peut accéder à l’application.

Faisons un récapitulatif de ce que nous venons de voir :

• SAML se base sur des jetons XML pour faire du SSO. Il est déjà très bien implanté en entreprise mais peut-être lourd à mettre en place.
• OAuth n’est pas un standard de fédération d’identité mais un standard de délégation d’autorisation. Il ne permet donc pas de faire du SSO mais peut-être très utile pour sécuriser l’authentification entre services (notamment les API).
• OpenID Connect est une surcouche d’OAuth permettant de faire du SSO. Il se développe très rapidement de par sa facilité de mise en œuvre (jetons JWT). Bien que plus récent, la valeur ajoutée par rapport à SAML est relativement faible comparée à l’investissement que représenterait une migration de SAML vers OIDC. Sa mise en place est donc recommandée si le standard SAML n’est pas déjà en place dans l’organisation. Les compétences ne sont, quant à elles, pas tout à fait les mêmes. S’ajoute à cela qu’OIDC fonctionne très bien sur des terminaux mobiles, là où SAML trouve ses limites.

Conclusion

En conclusion, l’utilisation de SAML ou d’OIDC dépendra donc de la stratégie de l’entreprise. Dans le cas d’applications mobiles, OICD est la solution à privilégier. Dans le cas d’applications web, la question est plus complexe. Les compétences internes, l’existant en termes de technologie mais aussi la vision à long terme de ce que sera le SI sont autant d’éléments à prendre en considération. Quant à la sécurisation de l’accès aux API, OAuth est le standard que nous privilégions pour les infrastructures portées par nos collaborateurs.

Au-delà de ces aspects, il est indispensable de considérer le SSO comme un composant de la gestion des identités et des accès. Seule, cette organisation n’aura qu’un intérêt limité alors que dans une démarche plus globale d’IAM (Identity and Access Management), le SSO prend tout son sens.