top of page

SAML vs OAuth vs OpenID

L'authentification permet d'entrer dans un système et l'autorisation permet d'accéder à des fonctionnalités spécifiques au sein du même système.

  • SAML (Security Assertion Markup Language) est une norme ouverte qui tente de combler le fossé entre l'authentification et l'autorisation.

  • OAuth est une norme d'autorisation ouverte.

  • OpenID Connect est une norme d'authentification qui s'exécute sur OAuth 2.0. Les différences entre ces normes et leurs rôles en matière d'authentification et d'autorisation sont détaillées ci-dessous.

Qu’est-ce que SAML ?

  • SAML 2.0 est une norme ouverte permettant de transmettre des informations d'authentification et d'autorisation entre trois acteurs, à savoir le mandant, le fournisseur de services et le fournisseur d'identité.

  • Le principal est l'utilisateur, le fournisseur de services est le propriétaire d'une ressource Web et le fournisseur d'identité exécute des services de gestion des accès aux identités.
    La plupart des implémentations SAML actuelles prennent toujours en charge la version précédente, SAML 1.1, pour des raisons de compatibilité ascendante.

  • SAML laisse au fournisseur d'identité le soin d'utiliser une méthode d'authentification appropriée, bien qu'il recommande la mise en œuvre d'une sécurité au niveau du transport et d'une sécurité au niveau du message.

    • Au lieu de cela, la norme impose l'utilisation de messages XML pour transmettre des informations entre le fournisseur de services et le fournisseur d'identité.

    • Connus sous le nom d’assertions de sécurité, ces messages peuvent être de trois types, à savoir :

      • Déclarations d'authentification : une assertion qui confirme au fournisseur de services que le fournisseur d'identité a authentifié un mandataire.

      • Déclarations d'attribut : contiennent un ou plusieurs attributs, ou paires nom-valeur, sur la base desquels l'accès est accordé au principal.

      • Déclarations de décision d'autorisation : affirmation selon laquelle un mandataire peut effectuer une ou plusieurs actions une fois qu'il a accès à la ressource Web fournie par le fournisseur de services.

  • SAML limite volontairement ce que les parties peuvent effectuer avec les assertions XML.
    Le langage XACML (Extensible Access Control Markup Language) basé sur XML peut être utilisé pour un contrôle d'accès plus précis.

Comment fonctionne SAML ?

  • L'échange SAML typique implique que le principal, via un navigateur Web ou un autre agent utilisateur, tente d'accéder à la ressource Web du fournisseur de services.

  • Le fournisseur de services envoie une demande d'authentification au fournisseur d'identité à l'aide du navigateur Web.

  • Le fournisseur d'identité peut demander à l'utilisateur de fournir un nom d'utilisateur ou un mot de passe, ou les deux.

  • Après vérification de l'identité de l'utilisateur, le fournisseur d'identité renvoie une assertion d'authentification, ainsi que les informations d'identification de l'utilisateur, au fournisseur de services.

  • Sur la base du message du fournisseur d'identité, le fournisseur de services autorise ou interdit la tentative de l'utilisateur d'accéder à son service.

  • SAML simplifie la mise en œuvre de l'authentification et de l'autorisation fédérées , qui impliquent plusieurs fournisseurs de services dans plusieurs organisations et domaines de sécurité à l'aide d'un seul fournisseur d'identité.

    • Un exemple d’identification fédérée est l’authentification unique (SSO).

    • En SAML, le SSO prend la forme d'un cookie de session de navigateur qui permet d'accéder à plusieurs applications.

Qu’est-ce qu’OAuth ?

  • OAuth est une norme ouverte d'autorisation qui accorde un accès délégué sécurisé aux applications, appareils, interfaces de programmation d'applications (API) et serveurs via des jetons d'accès.
    OAuth autorise une application à accéder à vos données sans lui donner accès à vos informations d'identification.

  • Avant OAuth, l'authentification de base HTTP était la forme la plus couramment utilisée pour accéder aux systèmes, nécessitant uniquement l'utilisation d'un nom d'utilisateur et d'un mot de passe.

    • Le SSO est apparu lorsque SAML est devenu populaire, mais le problème avec SAML est qu'il n'est pas particulièrement adapté aux applications monopage et aux applications Web modernes qui effectuent des appels HTTP en arrière-plan aux API via JavaScript et XML asynchrones (AJAX) et les services Web.

    • De plus, SAML n'est pas idéal pour les téléphones mobiles, les téléviseurs intelligents et l'Internet des objets.

    • OAuth, avec son utilisation de paquets JSON et d'appels API, est idéal pour le Web moderne.

  • Le flux de travail OAuth typique implique trois acteurs, à savoir l'utilisateur, le consommateur et le fournisseur de services.

    • Le flux de travail commence lorsque l'utilisateur montre au fournisseur de services son intention d'effectuer une action impliquant le consommateur.

    • Le consommateur obtient un jeton de demande et un secret du fournisseur de services, les transmet à l'utilisateur, puis redirige l'utilisateur vers le fournisseur de services afin que le premier puisse autoriser explicitement le jeton de demande avec le second.

    • Le fournisseur de services accorde ensuite un jeton d'accès qui permet au consommateur d'accéder à la ressource protégée au nom de l'utilisateur.

    • Les jetons d'actualisation ont souvent une durée de vie longue et peuvent être utilisés pour obtenir de nouveaux jetons d'accès auprès du fournisseur de services. En revanche, les jetons d’accès sont de courte durée.

  • OAuth n'est pas rétrocompatible avec la version antérieure d'OAuth 1.0a. OAuth 2.0 est plus largement utilisé, même si certains restent sur OAuth 1.0a.

    • Si vous envisagez d'utiliser OAuth, il est recommandé d'utiliser OAuth 2.0.

    • Outre une mise en œuvre plus simple, un autre avantage d'OAuth 2.0 est que les jetons transmis entre les acteurs sont chiffrés pendant le transit.

Qu’est-ce qu’OpenID Connect ?

  • Basé sur le protocole d'authentification décentralisé OpenID , OpenID Connect fournit une couche d'authentification au-dessus d'OAuth 2.0.
    Il répond à l'absence de mécanisme d'authentification dans OAuth, ce qui constitue une faiblesse lorsqu'il s'agit d'autoriser des transactions sensibles telles que les paiements.

  • Un flux de travail OpenID Connect typique implique trois parties, à savoir le client, l'utilisateur final et le fournisseur d'identité.

    • Le client, ou la partie utilisatrice, envoie l'utilisateur final au fournisseur d'identité, où l'utilisateur final authentifie l'identité et autorise l'accès au client.

    • Le fournisseur d'identité envoie un code d'autorisation au client, qui l'utilise ensuite pour demander des jetons d'accès et d'identification au fournisseur d'identité.

    • Une fois que le client obtient les jetons, il est autorisé à effectuer une action au nom de l'utilisateur final.

  • OpenID Connect utilise un jeton Web JSON signé et vérifiable cryptographiquement pour garantir que les jetons d'accès et d'identification ne sont pas falsifiés lors de l'échange d'informations entre les parties.

Quelles sont les différences entre OAuth, SAML et OpenID Connect ?

  • Bien que les cas d'utilisation d'OAuth, SAML et OpenID Connect soient variés, en termes de fonction, OAuth est utilisé dans l'autorisation d'accès tandis que SAML et OpenID Connect sont utilisés dans l'authentification des utilisateurs.

    • Ainsi, OAuth est utilisé dans des situations nettement différentes de celles de SAML et OpenID Connect.

    • Il peut également être utilisé avec SAML ou OpenID Connect.

  • OAuth

    • Vous avez peut-être utilisé OAuth lorsque vous avez autorisé une application, par exemple Trello, à accéder à vos contacts Gmail.

    • Dans cette situation, vous êtes l'utilisateur, Trello est le consommateur et Gmail est le fournisseur de services.

    • Gmail fournit les jetons qui permettent à Trello d'accéder à vos contacts.

  • Connexion OpenID

    • Dans le cas d'OpenID Connect, vous l'avez probablement utilisé si vous avez authentifié votre compte dans une autre application utilisant Facebook ou une autre application.

    • Vous vous connectez à Facebook, qui est le fournisseur d'identité, pour accéder à l'application tierce (par exemple Spotify).

    • Vous vous êtes peut-être connecté à Facebook, mais vos informations d'identification sont stockées en toute sécurité sur Facebook, à l'abri de toute menace potentielle au cas où Spotify serait piraté.

  • SAML

    • SAML est principalement utilisé dans les entreprises.

    • De nombreuses organisations l'utilisent pour connecter les utilisateurs aux réseaux internes.

    • Une fois connecté, vous n'avez pas besoin de saisir vos informations d'identification pour accéder aux applications du réseau.

bottom of page