Explorer l’authentification
L’authentification consiste à valider une identité (utilisateur, application ou appareil) qui est revendiquée. En outre, elle consiste ensuite à fournir un niveau approprié de validation et de sécurité tout au long de la transaction d’authentification. L’authentification des identités offre ce qui suit :
- Authentification flexible et conforme aux normes qui s’intègre à l’ensemble des organisations
- Intégration de sources, d’applications et de protocoles disparates
- Emploie de nombreuses méthodes de validation et d’assurance standard du secteur
L’utilisation d’un fournisseur d’identité pour l’authentification offre un moyen de garantir des identités sécurisées sans limiter les possibilités d’action des utilisateurs. Vous bénéficiez de diverses fonctionnalités : commodité, sources diverses pour valider l’identité, protocoles du secteur et assurance de l’identité.
Commodité : la fonctionnalité de commodité se concentre sur l’expérience des utilisateurs finaux, plus précisément sur la façon dont ils sont invités à entrer des informations d’authentification. Concentrez-vous ici sur l’expérience de l’utilisateur final. Si quelque chose n’est pas facile, les utilisateurs l’évitent ou s’en plaignent.
Sources : la fonctionnalité de sources concerne l’emplacement à partir duquel l’utilisateur obtient son jeton d’authentification. De nombreuses organisations pensent avoir un émetteur centralisé (Microsoft Entra ID), mais en réalité, la plupart des organisations ont également d’autres dépôts d’identités. L’identité fédérée est l’autre fournisseur d’identité le plus courant.
Protocoles : souvent, les organisations disposent de divers protocoles d’authentification qui procurent une expérience insuffisante pour les utilisateurs finaux et l’organisation. Un domaine d’intérêt de cette fonctionnalité est d’aider une organisation à standardiser un ou plusieurs protocoles d’authentification modernes et sécurisés pour atteindre ses objectifs d’authentification.
Assurance : l’assurance de l’authentification est la confiance qu’une organisation a qu’une personne accédant à une ressource est celle qu’elle affirme être. Cette fonctionnalité détermine si une organisation utilise ou non des comptes partagés, si elle utilise des comptes personnalisés et si des solutions telles que l’authentification multi-facteur ou l’authentification basée sur les risques sont en place.
Identité fédérée
La fédération est une collection de domaines pour lesquels une confiance est établie. Le niveau de confiance varie, mais il inclut généralement l’authentification et presque toujours l’autorisation. Cette fédération vous permet d’appliquer les identités existantes à partir de sources approuvées, telles qu’un annuaire actif local existant.
Protocoles de communication courants dans l’identité
Protocol | Description et utilisation |
---|---|
SAML - Security Assertion Markup Language | Norme ouverte pour l’échange de données d’authentification et d’autorisation entre un fournisseur d’identité et un fournisseur de services. Attributs SAML courants : |
Principal = généralement un utilisateur ou un appareil, IdP = fournisseur d’identité, SP = fournisseur de services | |
IdP = fournisseur d’identité | |
SP = fournisseur de services | |
WS-Fed - Web Services Federation | Spécification d’identité du framework de sécurité des services web pour fournir l’authentification unique via l’échange et l’authentification d’identités externes. |
OIDC - OpenID Connect | OIDC étend le protocole d’autorisation OAuth 2.0 pour l’utiliser en tant que protocole d’authentification, ce qui vous permet de procéder à une authentification unique à l’aide d’OAuth. |
OpenID Connect
OpenID Connect (OIDC) est un protocole d’authentification basé sur OAuth 2.0. Ce protocole permet à un utilisateur de se connecter de manière sécurisée à une application. En utilisant l’implémentation d’OpenID Connect provenant de la plateforme d’identités Microsoft, vous pouvez ajouter l’accès à la connexion et aux API à vos applications. OpenID Connect étend le protocole d’autorisation OAuth 2.0 pour l’utiliser en tant que protocole d’authentification, ce qui vous permet de procéder à une authentification unique à l’aide d’OAuth. OpenID Connect introduit le concept de jeton d'ID, qui est un jeton de sécurité permettant au client de vérifier l’identité de l’utilisateur. Il permet également les informations de base de profil de l'utilisateur. Il présente également le point de terminaison de UserInfo, une API qui renvoie des informations sur l’utilisateur.
Identité basée sur les revendications dans Microsoft Entra ID
Quand un utilisateur se connecte, Microsoft Entra ID envoie un jeton d’ID qui contient un ensemble de revendications concernant l’utilisateur. Une revendication est simplement une information, exprimée sous la forme d’une paire clé/valeur. Par exemple, email=bob@contoso.com. Les revendications ont un émetteur (dans ce cas, Microsoft Entra ID) qui est l’entité qui authentifie l’utilisateur et crée les revendications. Vous approuvez les revendications, car vous approuvez l’émetteur. (À l’inverse, si vous n’approuvez l’émetteur, n’approuvez pas les revendications !)
À un niveau élevé :
- L’utilisateur s’authentifie.
- Le fournisseur d'identité (IDP) envoie un ensemble de revendications.
- L’application normalise ou renforce les revendications (facultatif).
- L’application utilise les revendications pour prendre des décisions d’autorisation.
Dans OpenID Connect, l’ensemble de revendications que vous obtenez est contrôlé par le paramètre d’étendue de la requête d’authentification. Toutefois, Microsoft Entra ID émet un ensemble limité de revendications avec OpenID Connect en utilisant un jeton de sécurité, principalement des jetons JWT (JSON Web Token). Pour obtenir davantage d’informations sur l’utilisateur, utilisez l’API Graph avec Microsoft Entra ID.
Jetons de sécurité
La plateforme d’identités Microsoft authentifie les utilisateurs et fournit des jetons de sécurité, tels que des jetons d’accès, des jetons d’actualisation et des jetons d’ID. Les jetons de sécurité permettent à une application cliente d’accéder à des ressources protégées sur un serveur de ressources. Il existe trois types courants de jetons : jetons d’accès, jetons d’actualisation et jetons d’ID.
- Jeton d’accès : un jeton d’accès est un jeton de sécurité émis par un serveur d’autorisation dans le cadre d’un flux OAuth 2.0. Il contient des informations sur l’utilisateur et la ressource à laquelle le jeton est destiné. Les informations peuvent être utilisées pour accéder à des API web et à d’autres ressources protégées. Les jetons d’accès sont validés par des ressources pour accorder l’accès à une application cliente. Pour en savoir plus sur la façon dont la plateforme d’identités Microsoft émet des jetons d’accès, consultez Jetons d’accès.
- Jeton d’actualisation : les jetons d’accès n’étant valides que pendant une courte période, les serveurs d’autorisation émettent parfois un jeton d’actualisation en même temps que le jeton d’accès. L’application cliente peut alors échanger ce jeton d’actualisation contre un nouveau jeton d’accès si nécessaire. Pour en savoir plus sur la façon dont la plateforme d’identités Microsoft utilise les jetons d’actualisation pour révoquer les autorisations, consultez Jetons d’actualisation.
- Jeton d’ID : les jetons d’ID sont envoyés à l’application cliente dans le cadre d’un flux OpenID Connect. Ils peuvent être envoyés en même temps qu’un jeton d’accès ou à la place de celui-ci. Les jetons d’ID sont utilisés par le client pour authentifier l’utilisateur. Pour en savoir plus sur la façon dont la plateforme d’identités Microsoft émet des jetons d’ID, consultez Jetons d’ID.
Qu’est-ce qu’un jeton web JSON (JWT) ?
JSON Web Token (JWT) est une norme ouverte (RFC 7519) qui définit un moyen compact et autonome de transmettre de manière sécurisée des informations entre des parties en tant qu’objet JSON. Ces informations peuvent être vérifiées et approuvées, car elles sont signées numériquement. Les jetons JWT peuvent être signés à l’aide d’un secret ou d’une paire de clés publique/privée. Même si les jetons JWT peuvent être chiffrés pour assurer également la confidentialité entre les parties, nous nous concentrons sur les jetons signés. Les jetons signés peuvent vérifier l’intégrité des revendications qu’ils contiennent, tandis que les jetons chiffrés masquent ces revendications aux autres parties. Quand des jetons sont signés à l’aide de paires de clés publique/privée, la signature atteste également que seule la partie qui contient la clé privée est celle qui l’a signée.
Notes
Informations fournies à partir du site web JWT - https://jwt.io/.
Définitions au sein d’une identité basée sur les revendications
Certains termes courants sont utilisés dans le cadre de l’identité basée sur les revendications dans Microsoft Entra ID.
- Revendication : paire de valeurs de données au sein d’un jeton de sécurité. Il existe plusieurs revendications transférées dans le jeton, de la revendication qui définit le type du jeton à la méthode de chiffrement. Voici un exemple :
Header { "alg": "HS256", "typ": "JWT" } Content payload { "sub": "1234567890", "name": "John Doe", "aud": "https://jwt.io" }
- Assertion : package de données, généralement sous forme de jeton qui partage les informations d’identité et de sécurité d’un utilisateur ou d’un compte dans les domaines de sécurité.
- Attribut : paire de valeurs de données au sein d’un jeton.
- Augmentation : processus d’ajout de revendications au jeton utilisateur pour fournir d’autres détails sur l’utilisateur. Cela peut inclure des données provenant de systèmes de ressources humaines (RH), d’une application comme SharePoint ou d’autres systèmes.