SAML (SAML 1.0 et 2.0) et OpenID Connect (OIDC) sont des protocoles d'identité conçus pour authentifier les utilisateurs, fournir des données d'identité nécessaires au contrôle d'accès et comme méthode de communication pour l'identité des utilisateurs. L'un ou l'autre de ces protocoles peut servir de base à des fournisseurs d'identité (IdP) qui offrent une gamme de services et la gestion de l'identité des utilisateurs. Ils peuvent être utilisés pour supporter des applications d'authentification unique (SSO).

Principalement utilisée pour les applications d'entreprise et gouvernementales, SAML 2.0 est une technologie mature datant de 2.0. Elle prend en charge une large gamme de fonctionnalités d'identité. SAML utilise XML pour son format de données d'identité et de simples mécanismes de transport de données HTTP ou SOAP. Le service qui demande et reçoit des données de l'IdP est connu sous le nom de « partie de confiance » (Relying Party, RP). Les données d'identité de l'utilisateur, encapsulées dans un document XML appelé Assertion SAML, se présentent sous la forme d'attributs, par exemple l'adresse électronique, le nom, le téléphone, etc.

SAML peut fournir un mécanisme d'identité fédérée

Avant qu'un fournisseur de services/récepteur puisse interagir avec un IdP pour authentifier des utilisateurs, des métadonnées doivent être échangées entre la RP et l'IdP. Ces métadonnées, au format XML, spécifient les points de terminaison, les certificats de signature et de chiffrement, les méthodes de connexion prises en charge, le format des attributs, etc. que chaque partie du binaire SAML doit connaître sur l'autre. Chaque partie utilise ensuite les métadonnées de l'autre pour configurer son côté du système. Pour authentifier un utilisateur, la RP envoie une demande d'authentification (SAML AuthnRequest) à l'IdP, en utilisant soit un formulaire HTTP post (liaison POST), soit une redirection avec une chaîne de requête (liaison Redirect) pour effectuer la demande. Cette demande est normalement signée par la RP. L'IdP vérifie ensuite la demande, authentifie l'utilisateur et renvoie une réponse SAML, contenant l'assertion SAML avec les attributs convenus, à la RP dans un formulaire POST. Certains IdP prennent en charge le consentement de l'utilisateur à la divulgation des attributs, mais cela ne fait pas partie du protocole SAML. Normalement, les réponses et les assertions SAML sont signées numériquement par l'IdP. Les assertions peuvent également être cryptées si l'application considère que la protection HTTPS est insuffisante. SAML prend en charge une gamme d'options AuthnRequest qui permettent un comportement dynamique, par exemple les méthodes d'authentification des utilisateurs acceptables, la désactivation du SSO (forçant la connexion à l'IdP), la restriction des IdP proxy, etc. D'autres options personnalisées sont également prises en charge.

Protocole relativement nouveau, en constante évolution, OIDC a été conçu pour les applications Web et mobiles. Conçu pour être facile à adopter et à utiliser, OIDC est une extension d'OAuth2, avec des structures de données au format JSON (JWT) et des flux HTTPS simples pour le transport. Les données d'identité de l'utilisateur (« revendications ») sont émises dans un jeton Web JSON (jeton d'identification). Les revendications incluent un identifiant persistant et des données utilisateurs définies par les champs d'application demandés. Par convention, ce jeton est signé numériquement, et peut aussi être chiffré si nécessaire.

Les champs d'application OIDC sont utilisés pour préciser quelles revendications ou quels groupes de revendications peuvent être renvoyés par l'IdP. Les valeurs de champ d'application acceptables, et les revendications auxquelles elles se rapportent exactement, dépendent de l'IdP. OIDC définit un certain nombre de champs d'application et de revendications courants, tels que profil, adresse, courriel, etc.

À titre d'exemple, le champ d'application profil contient généralement le nom de l'utilisateur et peut inclure sa photo, sa date de naissance et d'autres données personnelles, en fonction des données dont dispose l'IdP et de celles qu’il estime nécessaire.

Comme SAML, avant de pouvoir utiliser OIDC, la RP et l'IdP doivent échanger certaines données. Cependant, ces données peuvent être beaucoup plus simples dans OIDC. Au minimum, la RP obtient un identifiant et un code secret client de la part de l'IdP, se met d'accord sur les champs d'application potentiels et indique à l'IdP un point de terminaison URL auquel renvoyer des codes ou des jetons.

Étant basé sur OAuth 2.0, OIDC comporte un certain nombre de cas d'utilisation, appelés flux, qui déterminent précisément comment la RP et l'IdP interagissent. Le flux le plus simple est le flux implicite, dans lequel la RP redirige vers l'IdP avec l'ID du client et les valeurs de champ d'application souhaitées. Lorsque l'utilisateur a été authentifié et a consenti à partager ces données, l'IdP renvoie les revendications dans le jeton d'identification en redirigeant vers le point de terminaison défini au préalable par la RP. Les flux plus sûrs n'impliquent pas l'envoi direct du jeton d'identification, mais plutôt le renvoi d'un code à usage unique, que la RP échange contre le jeton par le biais d'une requête POST back-end. Outre le jeton d'identification, un jeton d'accès peut également être émis. La RP peut l’utiliser pour autoriser les demandes de ressources utilisateurs couvertes par le champ d'application.

SAML a fait ses preuves en fournissant un moyen sécurisé d'échange de données d'identité, ce qui lui vaut la confiance de nombreuses organisations. Il est également très riche en fonctionnalités, couvrant une large plage d'exigences en matière d'identité. OIDC, plus récent et en pleine évolution (notamment dans le secteur bancaire européen, avec Open Banking), est encore en retard sur SAML en termes de fonctionnalités. Par exemple, la spécification dynamique des IdP proxy n'est pas encore totalement prise en charge. Cependant, pour de nombreuses applications ayant une simple exigence de données d'identité de base, en particulier dans le domaine de la consommation, OIDC est très attrayant, car il est beaucoup plus facile à utiliser que SAML, et il ne nécessite pas de traitement XML lourd comme SAML.

Actuellement, SAML est largement utilisé pour l'identification des citoyens et l'authentification des entreprises par l'administration. Toutefois, cette situation évolue et des systèmes plus modernes exigent OIDC à la place de SAML. Cela est dû à la légèreté perçue du traitement des données dans OIDC, qui utilise des jetons JSON (jeton d'identification) au lieu de XML. Le protocole OIDC est idéal pour les applications mobiles et les applications Web à page unique, pour lesquelles l'utilisation de SAML s'avère difficile.

Poursuivez la lecture de notre page Introduction à l'IAM pour explorer d'autres sujets relatifs à la gestion des identités et des accès.