Comprendre IAM, OAuth, OpenID Connect, SAML, SSO et JWT dans un article

Le domaine de la gestion des identités et des accès (IAM) est devenu plus complexe ces dernières années. Les termes habituels comme OAuth, OpenID Connect (OIDC), SAML, SSO et JWT sont souvent utilisés, mais que signifient-ils ? Comment fonctionnent-ils ensemble ? Explorons ces concepts et cadres pour les rendre plus compréhensibles et pratiques.

Qu'est-ce que l'IAM ?#

La gestion des identités et des accès (IAM) est un concept large qui implique la gestion des identités numériques et la mise en œuvre du contrôle d'accès. Les cadres et protocoles mentionnés précédemment relèvent de l'IAM, chacun abordant des défis spécifiques dans ce domaine.

En essence, l'IAM concerne :

• Identité : Une représentation numérique d'un utilisateur, d'un service ou d'un appareil. Une identité inclut généralement des attributs tels que le nom, l'email, les rôles, etc., pour décrire l'entité.
• Accès : La capacité à interagir avec des ressources, effectuer des actions ou utiliser des services. L'accès définit quelles actions peuvent être effectuées sur quelles ressources.

Dans le diagramme ci-dessus, un utilisateur (identité) souhaite effectuer une requête GET sur une API (ressource). Les attributs de l'utilisateur - nom, email et rôle - décrivent l'identité.

Authentification vs autorisation#

L'authentification et l'autorisation apparaissent souvent ensemble dans les discussions sur l'IAM. Clarifions leurs définitions :

• Authentification : Le processus de vérification de la propriété d'une identité. Il répond à la question : "Quelle identité possédez-vous ?"
• Autorisation : Le processus de détermination des actions qu'une identité authentifiée peut effectuer sur une ressource. Il répond à la question : "Que pouvez-vous faire ?"

Dans l'exemple précédent :

• Avant que l'utilisateur (identité) puisse effectuer des actions, il doit compléter le processus d'authentification.
• Après l'authentification, le système doit déterminer si l'utilisateur peut effectuer une requête GET (action) sur l'API (ressource), c'est-à-dire compléter le processus d'autorisation.

---

Armés de cette connaissance fondamentale, démystifions les autres acronymes et protocoles.

OAuth#

OAuth 2.0, communément appelé OAuth, est un cadre d'autorisation qui permet à une application d'accéder à des ressources protégées sur une autre application (typiquement au nom d'un utilisateur).

Par exemple, imaginez que vous avez une application web appelée MonAppli qui souhaite accéder au Google Drive d'un utilisateur. Au lieu de demander à l'utilisateur de partager ses identifiants Google Drive, MonAppli peut utiliser OAuth 2.0 pour demander l'autorisation (autorisation) de Google pour accéder au Drive de l'utilisateur.

Voici un diagramme simplifié illustrant le processus OAuth :

Dans ce processus :

• MonAppli est le client (identité) demandant l'accès à Google Drive (ressource).
• L'utilisateur (propriétaire de la ressource) accorde à MonAppli la permission à l'étape 6, complétant le processus d'autorisation.

Un élément clé de OAuth 2.0 est le jeton d'accès, que le client utilise pour démontrer l'autorisation de l'utilisateur à accéder aux ressources. Pour en savoir plus, consultez Jeton d'accès.

OpenID Connect (OIDC)#

OpenID Connect (OIDC) est une couche d'authentification construite sur OAuth 2.0. Elle ajoute des fonctionnalités spécifiquement pour l'authentification, telles que les jetons d'identité et un point de terminaison UserInfo, ce qui la rend adaptée à la fois pour l'authentification et l'autorisation.

Si nous revisitons le flux OAuth, ajouter OIDC introduit un jeton d'identité. Ce jeton contient des informations sur l'utilisateur authentifié et permet à MonAppli de vérifier l'identité de l'utilisateur.

Scénario d'exemple : "Se connecter avec Google"#

Changeons d'exemple. Si MonAppli veut permettre aux utilisateurs de se connecter en utilisant leurs comptes Google, l'objectif se déplace vers l'authentification plutôt que l'accès aux ressources. Dans ce cas, OIDC est plus adapté. Voici à quoi ressemble le flux OIDC :

Différence essentielle : En plus d'un jeton d'accès, OIDC fournit un jeton d'identité, qui permet à MonAppli d'authentifier l'utilisateur sans nécessiter de demandes supplémentaires.

OIDC partage les définitions de délégation d'OAuth 2.0, garantissant la compatibilité et la cohérence entre les deux cadres.

SAML#

Security Assertion Markup Language (SAML) est un cadre basé sur XML pour échanger des données d'authentification et d'autorisation entre des parties. SAML, introduit au début des années 2000, a été largement adopté dans les environnements d'entreprise.

Comment SAML se compare-t-il à OIDC ?#

SAML et OIDC sont fonctionnellement similaires mais diffèrent dans leurs détails de mise en œuvre :

• SAML : Utilise des assertions basées sur XML et est souvent considéré comme plus complexe.
• OIDC : Utilise JSON et JWT, ce qui le rend plus léger et plus convivial pour les développeurs.

Les applications modernes préfèrent souvent OIDC pour sa simplicité et sa flexibilité, mais SAML reste répandu dans les systèmes hérités et les cas d'utilisation en entreprise.

Single sign-on (SSO)#

Single sign-on (SSO) est un schéma d'authentification qui permet aux utilisateurs d'accéder à plusieurs applications et services avec une seule série d'identifiants. Au lieu de se connecter individuellement à chaque application, l'utilisateur se connecte une fois et accède à tous les systèmes connectés.

Comment fonctionne le SSO ?#

Le SSO repose sur un fournisseur d'identité (IdP) central pour gérer les identités des utilisateurs. L'IdP authentifie l'utilisateur et fournit des services tels que l'authentification et l'autorisation aux applications connectées.

L'IdP peut utiliser des protocoles comme OIDC, OAuth 2.0, SAML, ou d'autres pour offrir ces services. Un seul IdP peut prendre en charge plusieurs protocoles pour répondre aux besoins divers des différentes applications.

Exemple de SSO basé sur OIDC#

Explorons un exemple de SSO basé sur OIDC :

Dans ce flux, l'utilisateur se connecte à l'IdP une fois et est authentifié sur plusieurs applications (AppA et AppB).

SSO d'entreprise#

Bien que le SSO soit un concept large, vous pouvez également rencontrer le terme SSO d'entreprise, qui se réfère à un type spécifique de SSO conçu pour les environnements d'entreprise (typiquement pour les employés et les partenaires).

Lorsqu'un client demande le SSO pour votre application, il est important de clarifier ses besoins et les protocoles qu'il utilise. Dans la plupart des cas, cela signifie que pour des domaines email spécifiques, ils veulent que votre application redirige les utilisateurs vers leur IdP (qui implémente le SSO d'entreprise) pour l'authentification.

Exemple : ajout d'un fournisseur de SSO d'entreprise#

Voici un exemple simplifié d'intégration d'un fournisseur de SSO d'entreprise (Banana) avec votre application (MonAppli) :

JWT#

JSON Web Token (JWT) est une norme ouverte définie dans la RFC 7519 qui permet une communication sécurisée entre deux parties. C'est le format standard pour les jetons d'identité dans OIDC et est largement utilisé pour les jetons d'accès OAuth 2.0.

Voici les caractéristiques clés de JWT :

• Compact : Les JWT sont des objets JSON encodés dans un format compact, ce qui les rend faciles à transmettre et à stocker.
• Autonome : Les JWT contiennent toutes les informations nécessaires sur l'utilisateur et le jeton lui-même.
• Vérifiable et encryptable : Les JWT peuvent être signés et chiffrés pour assurer l'intégrité et la confidentialité des données.

Un JWT typique ressemble à ceci :

Ce JWT se compose de trois parties séparées par des points :

• En-tête : Contient des métadonnées sur le jeton, telles que le type de jeton et l'algorithme de signature.
• Charge utile : Contient des informations sur l'identité et le jeton lui-même.
• Signature : Vérifie l'intégrité du jeton.

L'en-tête et la charge utile sont des objets JSON encodés en base64. Le JWT ci-dessus peut être décodé comme suit :

Grâce au JWT, le client peut décoder le jeton et extraire les informations de l'utilisateur sans faire de demandes supplémentaires au fournisseur d'identité. Pour en savoir plus sur le JWT, visitez JSON Web Token (JWT).

Récapitulatif#

Nous avons couvert beaucoup de sujets dans cet article. Résumons les points clés avec un exemple :

Imaginez que vous avez une application web, AppA, qui nécessite une solution de gestion des identités et des accès (IAM). Vous choisissez Logto, un fournisseur d'identité qui utilise OpenID Connect (OIDC) pour l'authentification. Comme OIDC est construit sur OAuth 2.0, Logto prend également en charge l'autorisation pour votre application.

Pour réduire les frictions pour vos utilisateurs, vous activez "Se connecter avec Google" dans Logto. Cela utilise OAuth 2.0 pour échanger des données d'autorisation et des informations utilisateur entre Logto et Google.

Après que l'utilisateur se soit connecté à AppA via Logto, AppA reçoit un jeton d'identité, qui est un JSON Web Token (JWT) contenant les informations de l'utilisateur.

À mesure que votre entreprise se développe, vous lancez une nouvelle application, AppB, qui nécessite également l'authentification des utilisateurs. Comme Logto est déjà configuré, vous pouvez réutiliser le même flux d'authentification pour AppB. Vos utilisateurs peuvent désormais se connecter à la fois à AppA et à AppB avec un seul jeu d'identifiants, une fonctionnalité connue sous le nom de single sign-on (SSO).

Plus tard, un partenaire commercial vous demande de connecter leur système de SSO d'entreprise, qui utilise le Security Assertion Markup Language (SAML). Vous découvrez que Logto prend en charge les connexions SAML, vous configurez donc une connexion entre Logto et le système SSO du partenaire. Désormais, les utilisateurs de l'organisation du partenaire peuvent également se connecter à AppA et AppB en utilisant leurs identifiants existants.

---

J'espère que cet article a clarifié ces concepts pour vous. Pour des explications et exemples plus approfondis, consultez Auth Wiki. Si vous cherchez une solution IAM pour votre application, envisagez d'utiliser un service géré comme Logto pour gagner du temps et des efforts.