Standards d’authentification et d’autorisation

Les modèles et les standards d’authentification et d’autorisation les plus connus en gestion des identités et des accès (IAM) sont OAuth, OpenID Connect (OIDC) et SAML (Security Assertion Markup Language). 

La différence principale entre ces standards est le fait que OAuth, désormais connu sous le nom de OAuth 2.0, est un modèle d’autorisation utilisé pour protéger des ressources spécifiques, comme des applications ou des ensembles de fichiers, tandis que SAML et OIDC sont des standards d’authentification utilisés pour créer des expériences de connexion sécurisées.

SAML

Le SAML (Security Assertion Markup Language) est un standard de fédération ouvert qui permet le single sign on (SSO). C’est le standard le plus ancien des trois et le plus couramment utilisé par les entreprises pour permettre à leurs utilisateurs d’accéder aux applications et aux services basés sur le web pour lesquels ils payent. Salesforce et Gmail sont des exemples d’applications auxquelles les employés accèdent après avoir réalisé une connexion SAML avec succès.

Le SAML est un modèle basé sur XML, ce qui signifie qu’il est extrêmement flexible, qu’il peut être utilisé sur n’importe quelle plateforme, et peut être transmis par une variété de protocoles dont HTTP et SMTP. Les informations d’authentification sont échangées entre les fournisseurs d’identité et les fournisseurs de service pour vérifier l’identité et les permissions de l’utilisateur, puis accorder ou refuser leur accès aux applications.

Largement utilisé dans les organisations commerciales, le SAML a été créé pour prendre en charge le SSO sur les applications et les services basés sur le navigateur. Il ne prend pas en charge le SSO pour les applications mobiles et les applications qui accèdent aux ressources à travers l’API.
 

OAuth

OAuth, désormais connu sous le nom de OAuth 2.0, est une structure de standard ouvert pour l’autorisation des API. Il est important de noter que OAuth est un protocole d’autorisation et non un protocole d’authentification, mais les informations sur l’utilisateur peuvent être utilisées pour le processus d’autorisation. Il définit comment le client d’un API peut obtenir des jetons de sécurité qui contiennent un ensemble de permissions pour les ressources disponibles par le biais d’une API.  

Au lieu de demander à un utilisateur de partager ses identifiants de connexion avec une application pour que cette application puisse accéder à une autre, OAuth délègue les décisions d’autorisation à un serveur d’autorisation distinct qui héberge le compte de l’utilisateur. En bref, OAuth agit au nom de l’utilisateur, en fournissant un accès délégué à un service tiers sans que l’utilisateur expose ses identifiants à ce tiers.

La chose la plus importante à comprendre est peut-être que OAuth n’est pas un protocole d’authentification. Par exemple, OAuth ne définit par un format de jeton spécifique ou un ensemble commun de portées pour le jeton d’accès. Il ne concerne pas non plus la manière dont une ressource protégée valide un jeton d’accès.

OAuth prend également en charge les cas d’usage service-to-service et device-to-service, alors que SAML ne le fait pas.
 

OpenID Connect (OIDC)

Le protocole OpenID Connect (OIDC) ajoute une couche d’authentification et d’identité à OAuth 2.0 et c’est l’un des protocoles de sécurité les plus récents. À l’instar d’OAuth, il délègue l’authentification d’un utilisateur au fournisseur de service qui héberge le compte utilisateur et autorise les applications tierces à accéder au compte de l’utilisateur. Mais l’OIDC donne aussi accès aux applications mobiles, aux API et aux applications basées sur un navigateur. 

À chaque fois qu’un utilisateur se connecte à une application ou à un service avec OIDC, il est redirigé vers son fournisseur OpenID, où il s’authentifie avant d’être redirigé vers l’application ou le service.

Utilisez OIDC dans les situations où :
 

• Vous élaborez une nouvelle application à partir de zéro. En particulier si vous voulez que votre application soit disponible sur des appareils mobiles.
   

• Vous voulez définir ce qu’un utilisateur peut faire dans une application après avoir été authentifié.
   

• Les JWT vous seront plus utiles que XML.