Gestion des identités : SAML vs OAuth2 vs OpenID Connect
Tout a commencé avec les organisations qui avaient besoin d’un moyen de centraliser leurs systèmes d’authentification pour une meilleure gestion et sécurité. C’est là que l’authentification unique (SSO) est apparue. L’authentification unique (SSO) est un service centralisé d’authentification des sessions et des utilisateurs dans lequel un seul ensemble d’identifiants de connexion peut être utilisé pour accéder à plusieurs applications. Sa beauté réside dans sa simplicité ; le service vous authentifie sur une seule plateforme, ce qui vous permet de vous connecter de manière transparente à plusieurs services internes sans avoir à vous connecter et vous déconnecter à chaque fois.
Viennent ensuite les développeurs d’applications tierces qui souhaitent utiliser les API internes pour les intégrer à leurs produits et solutions, ce qui était clairement un défi. Ensuite, les réseaux sociaux sont arrivés et ont rendu les choses encore plus compliquées, nous avons actuellement des milliers d’applications qui prennent en charge l’authentification via les réseaux sociaux comme Facebook, Google, Twitter, LinkedIn, etc. Le problème dans ces architectures est le défi de garder les choses aussi simples que possible et d’augmenter la sécurité en même temps. La solution ? Les identités fédérées.
Actuellement, les trois protocoles majeurs pour l’identité fédérée sont : SAML, OAuth2 & OpenID Connect. Avant de plonger profondément dans ces trois protocoles, discutons de certains concepts courants que les gens ont tendance à confondre.
Lorsqu’il s’agit de sécurité et d’accès, l’authentification & l’autorisation sont deux termes que les gens ont tendance à négliger et qui sont souvent confondus avec la même chose. Eh bien, l’authentification consiste à vérifier votre identité alors que l’autorisation consiste à vérifier ce à quoi vous avez accès.
L’authentification consiste à valider les informations de connexion avant de donner à l’utilisateur l’accès au système. En matière de sécurité, il est recommandé d’utiliser au moins deux facteurs d’authentification avant d’accorder à l’utilisateur l’accès à quoi que ce soit. (2FA, MFA, jetons numériques & physiques, etc.).
L’autorisation intervient après le processus d’authentification en vérifiant vos droits avant de vous accorder l’accès aux ressources requises telles que les bases de données, fichiers, référentiels, etc. Un exemple pratique serait une fois que les connexions d’un employé ont été vérifiées, est de voir à quels étages il a accès.
Les deux autorisations & authentification sont cruciales pour la sécurité et la gestion des accès et bien qu’elles aient toutes deux des concepts différents derrière elles, elles sont un élément critique de l’infrastructure d’un système et leur compréhension est essentielle pour la gestion des identités et des accès.
SAML
Le langage SAML (Security Assertion Markup Language) est une norme ouverte basée sur XML utilisée pour les implémentations d’authentification unique (SSO). SAML 2.0 a été publié en 2005 et constitue la version actuelle de la norme.
SAML est utilisé à la fois pour l’authentification & l’autorisation entre deux parties : un fournisseur de services (Office365, Salesforce, G Suite, etc.) & un fournisseur d’identité (Okta, OneLogin, Ping Identity, etc.). Le fournisseur de services (SP) accepte de faire confiance au fournisseur d’identité (IdP) dans le processus d’authentification. Cela se fait par le biais d’un document SAML XML envoyé par l’IdP contenant l’autorisation de l’utilisateur & authentification, puis redirigé vers le fournisseur de services.
Examinons cet exemple :
- Fournisseur d’identité (IdP) : Okta
- Fournisseur de services (SP) : Application Salesforce
- L’utilisateur tente de se connecter à l’application Salesforce de son entreprise depuis Chrome.
- L’application Salesforce répond en générant une requête SAML
- Chrome redirige l’utilisateur vers une URL SSO, Okta analyse la requête SAML, authentifie l’utilisateur (cela peut être via un nom d’utilisateur et un mot de passe, une authentification à deux facteurs ou MFA est l’utilisateur n’est pas sur le réseau interne de l’entreprise ; si l’utilisateur est déjà authentifié sur Okta, cette étape sera sautée) et génère une réponse SAML.
- Okta renvoie la réponse SAML codée à Chrome
- Chrome redirige la réponse SAML vers l’application Salesforce
- Si la vérification est réussie, l’utilisateur sera connecté à l’application Salesforce et aura accès à toutes les différentes ressources.
OAuth2
« Comment puis-je autoriser une application à accéder à mes données sans nécessairement lui donner mon mot de passe ? »
OAuth2 est un standard ouvert utilisé pour l’autorisation, il permet aux apps de fournir à l’application une » autorisation déléguée « . Contrairement à d’autres frameworks qui fournissent une authentification, OAuth autorise uniquement les appareils, API, serveurs avec des jetons d’accès plutôt que des informations d’identification et il fonctionne sur HTTPS.
Si vous avez déjà vu l’une des boîtes de dialogue ci-dessous, c’est ce dont nous parlons. C’est une application qui demande si elle peut accéder à des données en votre nom. Il s’agit d’OAuth.
Vous pouvez penser à cela comme des cartes-clés d’hôtel, mais pour les applications. Si vous avez une carte-clé d’hôtel, vous pouvez avoir accès à votre chambre. Comment obtenir une carte-clé d’hôtel ? Vous devez effectuer un processus d’authentification à la réception pour l’obtenir. Après vous être authentifié et avoir obtenu la carte-clé, vous pouvez accéder aux ressources dans tout l’hôtel.
OAuth définit quatre rôles :
- Propriétaire de la ressource : généralement l’utilisateur lui-même
- Client : Application demandant l’accès à un serveur de ressources
- Serveur de ressources : Serveur hébergeant des données protégées (par exemple Facebook hébergeant votre profil et vos informations personnelles)
- Serveur d’autorisation : Serveur délivrant un jeton d’accès au client. Ce jeton sera utilisé par le client pour demander le serveur de ressources.
Vous trouverez ci-dessous un schéma du flux OAuth2.
Envisageons cet exemple :
- Spotify veut accéder à votre liste d’amis depuis votre compte facebook.
- Vous êtes redirigé par Spotify vers le serveur d’autorisation (facebook dans ce cas)
- Si vous autorisez l’accès, le serveur d’autorisation envoie un code d’autorisation au client (Spotify) dans la réponse du callback.
- Puis, ce code est échangé contre un jeton d’accès entre le Facebook et Spotify.
- Maintenant Spotify est capable d’utiliser ce jeton d’accès pour interroger le serveur de ressources (Facebook) et récupérer votre liste d’amis.
Une chose à noter est que l’utilisateur ne voit jamais le jeton d’accès, il sera stocké dans la session. Le serveur d’autorisation envoie également d’autres informations telles que la durée de vie du jeton et un jeton de rafraîchissement.
OpenID Connect
OpenID Connect est une couche d’identité simple au-dessus du protocole OAuth 2.0 qui étend OAuth2 et permet une » authentification fédérée « .
Le flux de processus OpenID Connect est similaire au flux d’autorisation OAuth2, la différence majeure étant un ‘id-token’ qui permet l’authentification de l’utilisateur.
.
Notez que l’authentification fédérée est complètement différente de l’autorisation déléguée. Reprenons l’exemple de Facebook et Spotify
- L’authentification fédérée consiste à se connecter à Spotify en utilisant vos informations d’identification facebook.
- L’autorisation déléguée est la capacité d’une application externe à accéder aux ressources. Dans ce cas,,, Spotify essayant d’accéder à votre liste d’amis facebook pour l’importer dans Spotify.
Pour conclure, voici un tableau résumant les trois protocoles/frames.
.