Identité moderne : SAML, OIDC et approches hybrides

Le langage de balisage des assertions de sécurité 2.0 (SAML) est une norme ouverte fondée sur XML pour l’authentification unique dans les environnements d’entreprise. Standardisé en 2005, SAML permet à un fournisseur d’identité (IdP) d’émettre des assertions XML signées numériquement à destination de fournisseurs de services (SP), afin que les utilisateurs s’authentifient une seule fois et accèdent à plusieurs services sans saisir à nouveau leurs identifiants.

Dans SAML, le fournisseur d’identité (IdP) est l’autorité qui authentifie les utilisateurs et émet les assertions. Exemples : Okta, Microsoft Entra ID, PingFederate. Le fournisseur de services (SP) est l’application qui s’appuie sur l’assertion de l’IdP. Exemples : Salesforce, Workday, ServiceNow. Le SP fait confiance à la signature de l’IdP pour accorder l’accès.

Les assertions SAML doivent être signées numériquement par l’IdP à l’aide d’une paire de clés RSA ou EC, afin que le SP puisse en vérifier l’authenticité. Les assertions peuvent également être chiffrées pour assurer la confidentialité pendant leur transmission. Le SP doit valider la signature, vérifier les horodatages NotBefore et NotOnOrAfter de l’assertion et vérifier la restriction d’audience afin d’empêcher les attaques par rejeu.

OpenID Connect (OIDC) est une couche d’identité moderne fondée sur OAuth 2.0, qui remplit le même objectif d’authentification unique que SAML, mais utilise JSON et des JWT au lieu de XML. Publié en 2014, OIDC convient mieux aux applications mobiles, aux applications monopage et aux API REST, tandis que SAML reste dominant dans les applications web d’entreprise traditionnelles.

OIDC étend OAuth 2.0 en ajoutant un jeton d’identité (un JWT contenant des revendications d’identité) au flux d’autorisation OAuth 2.0. OAuth 2.0 gère l’autorisation (l’accès délégué aux API), tandis qu’OIDC ajoute l’authentification (la vérification de l’identité de l’utilisateur). OIDC exige la portée openid et renvoie un jeton d’identité en plus du jeton d’accès OAuth.

Microsoft Entra ID (anciennement Azure Active Directory) est un fournisseur d’identité cloud natif qui prend en charge SAML et OIDC/OAuth 2.0 pour l’authentification unique fédérée. Il peut se synchroniser avec Active Directory sur site via Entra Connect, assurant une gestion hybride des identités dans laquelle les ressources cloud et sur site partagent un répertoire d’identités unique.

Active Directory Federation Services (AD FS) est le serveur de fédération sur site de Microsoft, qui publie des points de terminaison SAML et WS-Federation pour Active Directory sur site. AD FS fait le lien entre les applications SAML héritées et les identifiants Active Directory et, dans les déploiements hybrides, se fédère avec Entra ID pour étendre l’authentification unique aux applications cloud.

System for Cross-domain Identity Management (SCIM) est une norme d’API REST qui automatise l’approvisionnement et le déprovisionnement des utilisateurs entre les systèmes d’identité et les applications. Lorsqu’un nouvel employé est ajouté à Entra ID ou à Okta, SCIM crée automatiquement les comptes correspondants dans les applications SaaS connectées et les supprime lorsque l’employé quitte l’entreprise.

Les fournisseurs d’identité modernes mettent en œuvre des règles d’accès conditionnel qui évaluent les signaux de risque (conformité de l’appareil, emplacement, comportement de l’utilisateur) avant d’accorder l’accès. Ces règles peuvent exiger une authentification multifacteur renforcée pour les ressources sensibles. Associé à l’authentification unique OIDC ou SAML, l’accès conditionnel assure une sécurité adaptative sans imposer une nouvelle authentification contraignante.

L’architecture de confiance zéro considère l’emplacement réseau comme sans importance pour les décisions d’accès : aucune confiance implicite n’est accordée du simple fait de se trouver sur le réseau de l’entreprise. Au lieu de l’authentification Kerberos fondée sur un périmètre, la confiance zéro utilise une vérification continue de l’identité, des contrôles de l’état de l’appareil et des règles d’accès selon le moindre privilège, appliqués à chaque demande d’accès à une ressource via OIDC ou SAML.

Utilisez SAML pour les applications d’entreprise héritées, conçues avant 2014 et prenant déjà en charge SAML. Utilisez OIDC pour les nouvelles applications, les applications mobiles, les applications monopage et les API. Les deux protocoles sont pris en charge par les principaux IdPs ; le choix dépend donc souvent de la prise en charge existante de l’application plutôt que de différences de sécurité. OIDC est le choix privilégié pour tout nouveau développement.

Quelle affirmation décrit correctement une différence clé entre SAML et OIDC ?

SAML 2.0 fournit une authentification unique fondée sur XML pour les applications d’entreprise traditionnelles. OIDC ajoute l’identité à OAuth 2.0 au moyen de jetons JWT et est privilégié pour les applications modernes. Entra ID prend en charge les deux protocoles comme IdP cloud hybride. AD FS fait le lien entre AD sur site et les applications fondées sur SAML. SCIM automatise l’approvisionnement. La confiance zéro remplace Kerberos fondé sur le périmètre par une vérification continue de l’identité pilotée par des règles.