Pourquoi cet article ?
La question me revient souvent en ce moment, de la part de mes étudiants, de collègues, de clients et lors d’échange avec mes pairs CTO / RSSI, et en particulier lorsque je fais des démos de l’intermédiation d’authentification avec Apache Keycloak (en utilisant une application cliente utilisant le protocole OpenID Connect). Je me suis dit que le plus simple, au lieu de continuer à répondre par oral, par mail ou dans des documents, serait de regrouper toutes les explications, normatives comme techniques, dans un seul article en ligne…
Bien définir la question
Ne vous attendez pas dans cet article à des déclarations à l’emporte-pièce sur le fait que tel ou tel protocole est obsolète ou que “SAML is dead” (référence). Que les choses soient claires dès le début : la question est juste de savoir pourquoi il vaut mieux privilégier OIDC à SAML pour de nouveaux déploiements. Si vous utilisez déjà du SAML, le protocole a beau être plus ancien, il ne possède pas de faiblesse qui nécessite son remplacement et l’IAM est un sujet trop important pour changer de mécanisme sans une excellente raison.
EDIT au 23/09/2024 : attention, une vulnérabilité de niveau CVSS 7.7 est désormais sous le code 2024-8698, et qui affecte spécifiquement SAML. A garder sous surveillance, donc, et si la situation se dégrade, ceci pourrait remettre en question le paragraphe ci-dessus.
La question à laquelle cet article répond est pourquoi utiliser OIDC plutôt que SAML si vous avez le choix, à savoir si vous n’êtes pas déjà équipé / si vous n’avez pas des conditions particulières qui vous forcent à prendre un des choix / etc. Nous expliquerons d’ailleurs brièvement ces cas particuliers qui pourraient vous amener à un choix plutôt qu’un autre.
Pas qu’une question de modernité
Comme rapidement expliqué, SAML est un protocole plus ancien qu’OIDC. Sa nouvelle version 2.0 a permis de dépasser les limites de la première version, mais elle date tout de même de 2005. Par comparaison, OAuth 2.0, qui est la brique de base d’OIDC, date de 2012. Une petite dizaine d’années en informatique, c’est un monde et les usages ont particulièrement évolué lors de ces sept ans, avec une démultiplication sans précédent des applications informatiques et en particulier web.
Mais dans des domaines aussi importants que l’Identity and Authorization Management, les principes et les implémentations évoluent finalement peu vite donc l’âge d’un protocole n’est pas vraiment un sujet en soi. Et les fonctionnalités elles-mêmes sont assez proches (référence). Voyons donc plutôt les autres critères.
Ouverture aux standards
SAML a été une des premières approches standardisées, par opposition aux mécanismes propriétaires de SSO. Mais OIDC est lui aussi standardisé, et présente l’avantage de s’appuyer sur de nombreux autres protocoles eux-mêmes normalisés.
Un des points très importants dans la capacité des SI à évoluer (l’urbanisation) est la séparation correcte des responsabilités, qui permet l’alignement business / IT. OIDC porte ce principe plus haut que SAML dans le sens où plusieurs normes et protocoles sont mis en œuvre pour les différentes fonctionnalités nécessaires au fonctionnement d’ensemble. OAuth est utilisé pour la gestion d’autorisation d’accès à une ressource, JWT est utilisé pour la normalisation du transport des données, RSA pour la signature, etc. A l’inverse, SAML définit en une seule norme toutes ces fonctionnalités, ce qui ne le rend pas plus simple, mais plus rigide, comme cela peut être constaté sur le faible nombre d’évolutions du standard.
Les standards se mélangent, toutefois, et on peut par exemple utiliser du OAuth avec des tokens SAML, même si, globalement, ceci complexifie plus les interactions dans un SI qu’autre chose. Au final, l’approche modulaire et standardisée à la fois d’OIDC est clairement un plus du protocole par rapport à SAML, qui accuse son âge sur ce point précis.
Adoption
Relative égalité sur ce point, OIDC étant sur une dynamique plus forte, mais SAML ayant une base installée encore très large. Une des raisons pour ceci, d’ailleurs, est simplement que le temps de déploiement d’une architecture d’authentification est très long et qu’une fois qu’une organisation a investi dedans, il ne suffit pas que le prochain protocole soit meilleur, il faut qu’il justifie un second investissement du même type. Toute entreprise ayant déployé un SSO avec tous les efforts que cela signifie n’a en général pas envie de recommencer l’année suivante.
Ainsi, SAML ayant commencé sa carrière plus tôt, il est logique que son parc installé soit étendu. Il est même notable que l’adoption augmente encore (référence), mais cela ne veut pas dire grand-chose dans notre comparatif, puisque ceci est complètement général à toutes les solutions d’IAM. Et ce fort heureusement car le taux d’équipement pour l’instant est dangereusement faible, avec toutes les problématiques de sécurité associées. La forte implantation d’Azure AD par le biais de la diffusion massive d’Office 365 dans les entreprises a beaucoup fait réduire ces risques. Azure AD a d’ailleurs le bon goût de proposer des endpoints SAML comme OIDC.
Fonctionnalités
SAML est particulièrement adapté à une gestion d’identité en mode “fermé”, c’est-à-dire dans le cadre interne de grandes entreprises, de réseaux d’universités, etc. A l’inverse, OIDC est pleinement adapté et pensé pour une utilisation sur des réseaux ouverts et bien sûr internet. Comme la bascule est de plus en plus forte sur le deuxième cas, OIDC devient le choix par défaut, internet intervenant maintenant dans presque tous les processus métier collaboratifs. OIDC va être plus adapté aux nouveaux usages comme les Single Page Applications, la mobilité, les applications natives hors navigateur, etc. (référence).
C’est peut-être sur ce point que la différence est la plus forte entre les deux produits et qui peut forcer un choix technologique. Toute entreprise qui a l’intention d’ouvrir, d’une manière ou d’un autre, sa gestion d’identité sur internet (que ce soit en accueillant des comptes B2C, en autorisant une authentification déléguée sur des IDP grand public, etc.) aura fortement intérêt à partir sur OIDC.
Le mécanisme d’anti-rejeu fourni par OIDC n’est pas implémenté en SAML. De plus, le fait qu’OIDC permettent de déléguer l’authentification à un autre IDP fait que le vol de crédentiels est plus complexes puisque dans ce cas, ils ne sont même pas connus du relais d’authentification lui-même. Enfin, OIDC permet, lors du protocole, de négocier les claims de manière beaucoup plus fine que SAML, même si les IDP pourraient encore améliorer ceci et permettre, par exemple, de refuser d’envoyer certaines informations demandées sans annuler complètement le mécanisme d’authentification. Le fait que l’identification soit incomplète par rapport aux claims demandés par le client devrait théoriquement relever de la responsabilité de ce dernier, quitte à ce qu’il puisse en retour refuser la connexion s’il considère que ce refus de livraison de claims est bloquant.
Mise en œuvre
De ce point de vue, les fonctionnalités standards de l’IAM (authentification, identification, production d’attributs dédiés à l’autorisation, voire même Policy Information Point, gestion de crédentiels et supports d’authentification, etc.) sont généralement offertes par OIDC de manière moins complexe que par SAML. Ce dernier est en effet plus verbeux, et pas seulement parce qu’il utilise du XML (un peu comme SOAP quand on le compare aux approches REST/JSON, sachant qu’on peut tout à fait faire du REST/XML). Par exemple, le chiffrement est intégré dans SAML, alors qu’OIDC se débarrasse complètement du sujet en le laissant à la couche HTTPS. Encore une fois, ceci participe d’un meilleur partage des responsabilités, caractéristique clé des architectures évolutives.
Ainsi, intégrer des clés FIDO ou Yubikey est un jeu d’enfant (bon, d’accord, un jeu d’adolescent bien motivé) avec OIDC. Et la simple mise en place d’un Shibboleth est bien plus complexe que de lancer un Keycloak. D’un côté, plusieurs heures au minimum et des documentations assez complexes à lire pour mettre en place le système de clés ; de l’autre, une simple commande Docker pour lancer l’image d’un Keycloak résolument plus moderne, et une interface graphique web pour paramétrer l’ensemble, plutôt que des fichiers de configuration.
En conclusion
SAML est loin d’être obsolète et va continuer à se déployer. Toutefois, il reste une solution legacy par rapport à OIDC. Si vous avez mis en place un SSO SAML, il n’y a aucune raison pour en changer. Si toutefois vous démarrez un projet d’IAM et que vous n’êtes pas encore équipé, à moins que certaines fonctionnalités spécifiques à SAML soient essentielles pour vous, le choix le plus couvrant et pérenne est OIDC. Il s’agit du protocole qui vous ouvre le plus de choix, de manière aussi sécurisée et avec un bien meilleur support des standards, donc plus de pérennité pour votre investissement.
Et pour aller plus loin
Mais le mieux est encore de ne pas avoir à choisir. Pour cela, intégrer un module d’IAM dans votre SI est l’approche la plus souple. En pratique, une solution comme Keycloak vous donnera la capacité d’intermédiation et vous permettra de connecter une application avec n’importe quel fournisseur d’authentification, qu’il soit compatible OIDC, SAML ou toute autre norme, voire même avec des protocoles complètement propriétaires (même si ceci nécessite de coder un petit JAR pour la médiation). Et si vous choisissez un annuaire, rappelez-vous que, pour peu que vous utilisiez Office 365 comme de nombreuses entreprises, vous bénéficiez déjà d’un annuaire en ligne compatible avec les deux normes du marché, ce qui vous ouvre à quasiment tous les usages.
