SAML et OAuth2 sont des protocoles standard ouverts et conçus avec des objectifs différents, mais apparentés. SAML 2.0 est principalement conçu pour authentifier un utilisateur, fournissant ainsi les données d'identité de l'utilisateur à un service. OAuth 2.0 est conçu comme un protocole d'autorisation permettant à un utilisateur de partager l'accès à des ressources spécifiques avec un fournisseur de services.

SAML (Security Assertion Markup Language) est un protocole bien établi et sécurisé, largement utilisé par les entreprises et les gouvernements pour le partage des données d'identité. Ces données utilisent des structures de données XML et de simples mécanismes de transport de données HTTP ou SOAP. Avec SAML, un Fournisseur d'identité (IdP) fournit des données utilisateur (attributs, tels que le nom, l'adresse électronique, etc.) lorsqu'un service ou une Partie de confiance (RP) le demande.

Avant toute transaction d'authentification, la partie de confiance (RP) et le fournisseur d'identité (IdP) doivent établir une relation de confiance. Cette relation est établie en échangeant quelques artefacts tels que des métadonnées, des points d'extrémité spécifiques, des certificats de signature et de cryptage, des méthodes de connexion prises en charge, etc.

Une fois ces éléments établis, la RP ayant besoin de l'identité d'un utilisateur envoie à l'IdP un formulaire POST (ou des redirections) avec une demande d'authentification, dans une session de navigateur Web. L'IdP authentifie alors l'utilisateur final par une connexion interactive et renvoie à la RP les données d'identité correspondantes (ensemble d'informations d'identification) dans une réponse SAML via un formulaire POST. Ces données d'identité comprennent toujours un identifiant que la RP peut utiliser pour identifier l'utilisateur. Dans le cadre de cette interaction, l'IdP peut également configurer une session d’authentification unique (SSO), afin que les demandes d'authentification provenant d'autres RP puissent sauter l'étape de connexion interactive. Si la RP a besoin d'attributs supplémentaires, ceux-ci peuvent être demandés dans le contexte de la session d’authentification unique en envoyant une requête d'attribut à l'IdP.

Normalement, les réponses SAML sont signées numériquement, afin de permettre la détection de la manipulation des données en transit. Ils peuvent être chiffrées si le chiffrement du transport (HTTPS) est insuffisant.

Publié pour la première fois en 2012, OAuth 2.0, également connu sous le nom de OAuth2, est un protocole d'autorisation conçu pour permettre aux utilisateurs de donner accès à leurs ressources hébergées par un fournisseur de services, sans donner d'informations d'identification. La nature des ressources de l'utilisateur n'est pas définie dans les spécifications du protocole, il peut donc s'agir de données ou d'autres entités. OAuth2 possède un large éventail de fonctionnalités qui lui permettent d’être utilisé par un grand nombre d'appareils et d'applications. De plus, OAuth2 est la base sur laquelle repose OpenID Connect, un protocole d'authentification populaire.

Dans la terminologie OAuth2, le service qui demande l'accès aux ressources des utilisateurs est le Client, et le service qui peut fournir ces ressources est le Serveur de ressources. L'accès aux ressources des utilisateurs détenues par le serveur de ressources est contrôlé par l'utilisation de jetons d'accès, des artefacts prouvant l'autorisation d'accès. OAuth2 fournit également un mécanisme, appelé ** champ d'application**, qui limite les autorisations sur la ressource d'un utilisateur. Le système qui authentifie l'utilisateur et répond finalement avec des jetons d'accès est le serveur d'autorisation.

Comme SAML, avant de pouvoir utiliser OAuth2, le client et le serveur de ressources doivent échanger certaines données avec le serveur d'autorisation. Au minimum, ils obtiennent un identifiant et un code secret du client auprès du serveur d'autorisation et conviennent des points de terminaison à appeler pour obtenir des informations spécifiques.

OAuth2 est très flexible et fournit à un client un certain nombre de flux, appelés attributions, pour obtenir un jeton d'accès. L’attribution à utiliser dépend principalement du type de client (application mobile, application native, client Web, etc.) et des exigences de sécurité globales. L'attribution la plus courante est sans doute celle du code d'autorisation, qui s'applique lorsque l'application cliente qui doit accéder à la ressource d'un utilisateur est une application Web ordinaire. Les paragraphes suivants décrivent brièvement les interactions entre le client, le serveur de ressources et le serveur d'autorisation dans le cadre de cette attribution :

1. Le client redirige l'utilisateur vers le serveur d'autorisation pour demander l'autorisation d'accéder à la ressource de l'utilisateur avec des champs d'application spécifiques.

2. Le serveur d'autorisation établit une connexion interactive avec l'utilisateur, qui confirme qu'il accorde les autorisations pour les champs d'application spécifiés.

3. Le serveur d'autorisation redirige l'utilisateur vers le terminal du client avec un code d'autorisation à usage unique.

4. Le client s'authentifie auprès du serveur d'autorisation et échange le code d'autorisation contre un jeton d'accès.

5. Avec le jeton d'accès, le client demande la ressource de l’utilisateur au serveur de ressources.

SAML prend en charge l'authentification unique tout en prenant également en charge l'autorisation par la méthode d'interrogation des attributs. OAuth est axé sur l'autorisation, même s'il est souvent contraint de jouer un rôle d'authentification, par exemple lors de l'utilisation d'une connexion à un réseau social du type « se connecter avec un compte Facebook ». Quoi qu'il en soit, OAuth2 ne prend pas en charge l’authentification unique.

D'un point de vue technique, SAML définit un format de jeton, mais son chiffrement est compliqué et la taille des messages échangés est importante. En revanche, OAuth2 n'utilise aucun chiffrement des messages (il s'appuie sur HTTPS) et ne définit pas de format de jeton.

L'intérêt d'OAuth2 réside dans sa facilité d'utilisation et sa flexibilité : il peut être utilisé dans des appareils mobiles, des appareils intelligents (par exemple, des téléviseurs intelligents), des applications Web, des applications monopages, etc. De nombreuses bibliothèques sont disponibles pour faciliter le processus d'intégration avec différents types de clients et de fournisseurs de services. Par contre, SAML n'a pas été conçu en tenant compte de ces applications modernes, ce qui rend son utilisation plus difficile sur ces systèmes. Il est couramment utilisé avec les applications Web traditionnelles.

SAML est généralement utilisé pour l’authentification unique dans les applications gouvernementales et d'entreprise (gestion de l'identité), où le traitement du XML par le système back-end est courant. De nombreux systèmes gouvernementaux d'identification des citoyens (par exemple, UK Verify) sont basés sur SAML.

OAuth2 est largement utilisé dans les applications grand public et d'entreprise, à la fois dans les rôles d'autorisation et d'authentification. Il est généralement utilisé pour autoriser l'accès aux API RESTful, pour lesquelles son utilisation de jetons d'accès le rend simple et attrayant.

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