Concepts d'OpenID Connect/OAuth dans AD FS

S’applique aux services de fédération Active Directory (AD FS) 2016 et versions ultérieures

Acteurs d’authentification modernes

Acteur	Descriptif
Utilisateur final	Principal de sécurité (utilisateurs, applications, services et groupes) qui accède à la ressource.
Client	Votre application web, identifiée par son ID client. Le client est généralement la partie avec laquelle l’utilisateur final interagit, et le client demande des jetons du serveur d’autorisation.
Serveur d’autorisation/fournisseur d’identité (IdP)	Votre serveur AD FS. Il est responsable de la vérification de l’identité des entités de sécurité figurant dans l’annuaire d’une organisation. Il émet des jetons de sécurité (jeton d'accès au porteur, jeton d'ID et jeton d'actualisation) lorsque l'authentification de ces responsables de la sécurité est réussie.
Serveur de ressources/fournisseur de ressources/partie de confiance	Où réside la ressource ou les données. Il a confiance dans le serveur d'autorisation pour authentifier et autoriser le client en toute sécurité et utilise des jetons d'accès au porteur pour permettre l'accès à une ressource.

Le diagramme suivant fournit la relation la plus simple entre les acteurs :

Types d’applications

Type d’application	Descriptif	Rôle
Application native	Parfois appelé client public. Il s’agit d’une application cliente qui s’exécute sur un pc ou un appareil et avec laquelle l’utilisateur interagit.	Demande des jetons du serveur d’autorisation (AD FS) pour l’accès utilisateur aux ressources. Envoie des requêtes HTTP aux ressources protégées à l’aide des jetons en tant qu’en-têtes HTTP.
Application serveur (application web)	Application web qui s’exécute sur un serveur et accessible aux utilisateurs via un navigateur. Étant donné qu’il est capable de conserver sa propre clé secrète client ou ses informations d’identification, il est parfois appelé client confidentiel.	Demande des jetons du serveur d’autorisation (AD FS) pour l’accès utilisateur aux ressources. Avant de demander un jeton, le client (application web) doit s’authentifier à l’aide de sa clé secrète.
API Web	La ressource finale accessible par l'utilisateur. Considérez-le comme la nouvelle représentation des parties prenantes.	Consomme les jetons d’accès du porteur obtenus par les clients.

Groupe d’applications

Vous devez associer un groupe d’applications à chaque client OAuth natif ou application web ou ressource d’API web configurée avec AD FS. Configurez les clients d’un groupe d’applications pour accéder aux ressources du même groupe. Un groupe d’applications peut avoir plusieurs clients et ressources.

Jetons de sécurité

L’authentification moderne utilise les types de jetons suivants :

• id_token : jeton JWT émis par le serveur d’autorisation (AD FS) et consommé par le client. Les informations du jeton d'ID contiennent des détails sur l'utilisateur, afin que l'application cliente puisse les utiliser.
• access_token : jeton JWT émis par le serveur d’autorisation (AD FS) et destiné à être consommé par la ressource. La revendication « aud » ou d’audience de ce jeton doit correspondre à l’identificateur de la ressource ou de l’API web.
• refresh_token : émis par AD FS pour que le client utilise lorsqu’il doit actualiser le id_token et le access_token. Le jeton est opaque pour le client et utilisé uniquement par AD FS.

Durées de vie des jetons d’actualisation

• Ouverture de session simple, sans KMSI, appareil non inscrit : AD FS applique SsoLifetime et DeviceUsageWindowInDays. Le premier jeton d’actualisation a lifetime=DeviceUsageWindowInDays ou SsoLifetime, en fonction de quel champ est inférieur, mais aucun autre jeton d’actualisation n’est émis.
• Connexion KMSI, EnableKmsi=true dans la configuration AD FS et kmsi=true passé en paramètre : AD FS applique KmsiLifetimeMins avec DeviceUsageWindowInDays. Le premier jeton d’actualisation a lifetime=DeviceUsageWindowInDays et chaque requête suivante grant_type=refresh_token obtient un nouveau jeton d’actualisation. Ce processus se produit uniquement avec les clients natifs ou les clients confidentiels, en plus de l'authentification des appareils.
• Appareils inscrits, authentification d’appareil : AD FS utilise PersistentSsoLifetimeMins et DeviceUsageWindowInDays ressemble à KMSI. Les clients natifs et confidentiels doivent obtenir de nouveaux jetons d’actualisation, en fonction de l’authentification de l’appareil.

Pour en savoir plus, consultez la documentation de l’authentification unique AD FS.

Étendues

Lorsque vous inscrivez une ressource dans AD FS, vous pouvez configurer des étendues pour permettre à AD FS d’effectuer des actions spécifiques. En plus de configurer l’étendue, vous devez envoyer la valeur d’étendue dans la demande d’AD FS pour effectuer l’action. Par exemple, un administrateur configure l’étendue comme openid pendant l’inscription des ressources, et l’application (client) doit envoyer le scope = openid dans la demande d’authentification pour qu'AD FS émette le jeton d'identité. Voici des détails sur les étendues disponibles dans AD FS :

• aza - Si vous utilisez des extensions de protocole OAuth 2.0 pour les clients broker et si le paramètre d’étendue contient l’étendue aza, le serveur émet un nouveau jeton d’actualisation principal. Il définit le jeton dans le refresh_token champ de la réponse et définit la refresh_token_expires_in field durée de vie du nouveau jeton d’actualisation principal si celui-ci est appliqué.
• openid - Permet à l’application d’utiliser le openid protocole d’authentification de connexion.
• logon_cert - Permet à une application de demander des certificats de connexion que vous pouvez utiliser pour vous connecter de manière interactive aux utilisateurs authentifiés. Le serveur AD FS omet le access_token paramètre de la réponse et fournit plutôt une chaîne de certificats CMS encodée en base64 ou une réponse PKI complète CMC. Pour plus d’informations, consultez MS-OAPX : extensions de protocole OAuth 2.0.
• user_impersonation - Demande un jeton d'accès au nom de AD FS. Pour plus d’informations sur l’utilisation de cette étendue, consultez Créer une application multiniveau à l’aide d’on-Behalf-Of (OBO) à l’aide d’OAuth avec AD FS 2016.
• allatclaims permet à l'application de demander que les déclarations dans le jeton d’accès soient également ajoutées au jeton d'identité.
• vpn_cert - Permet à une application de demander des certificats VPN, qui établissent des connexions VPN à l’aide de l’authentification EAP-TLS. Cette fonctionnalité n’est plus prise en charge.
• email : permet à l’application de demander une revendication par e-mail pour l’utilisateur connecté.
• profile : permet à l’application de demander des revendications liées au profil pour l’utilisateur connecté.

Réclamations

Les jetons de sécurité (jetons d’accès et d’ID) émis par AD FS contiennent des revendications ou des assertions d’informations sur le sujet qui a été authentifié. Les applications peuvent utiliser des revendications pour différentes tâches, notamment :

• Valider le jeton
• Identifier le locataire du répertoire du sujet
• Afficher les informations utilisateur
• Déterminer l’autorisation du sujet

Les revendications présentes dans un jeton de sécurité donné dépendent du type de jeton, du type d’informations d’identification utilisées pour authentifier l’utilisateur et de la configuration de l’application.

Flux d’authentification AD FS de haut niveau

Un diagramme du flux de haut niveau suit.

1. AD FS reçoit la demande d’authentification du client.

2. AD FS valide l’ID client dans la demande d’authentification avec l’ID client obtenu pendant l’inscription du client et des ressources dans AD FS. Si vous utilisez un client confidentiel, AD FS valide également la clé secrète client fournie dans la demande d’authentification. AD FS valide également l’URI de redirection du client.

3. AD FS identifie la ressource que le client souhaite accéder via le paramètre de ressource transmis dans la demande d’authentification. Si vous utilisez la bibliothèque de client MSAL, le paramètre de ressource n’est pas envoyé. Au lieu de cela, l’URL de ressource est envoyée dans le cadre du paramètre d’étendue : scope = [url de ressource]/[valeurs d’étendue, par exemple, openid].

   Si la ressource n'est pas transmise à l'aide des paramètres de ressource ou de périmètre, AD FS utilise une ressource urn:microsoft:userinfo par défaut dont les stratégies, telles que l'authentification multifacteur, l'émission ou d'autorisation, ne peuvent pas être configurées.

4. Ad FS suivant vérifie si le client dispose des autorisations nécessaires pour accéder à la ressource. AD FS vérifie également si les étendues passées dans la demande d’authentification correspondent aux étendues configurées lors de l’inscription de la ressource. Si le client n’a pas les autorisations ou si les étendues appropriées ne sont pas envoyées dans la demande d’authentification, le flux d’authentification se termine.

5. Une fois les autorisations et les étendues validées, AD FS authentifie l’utilisateur à l’aide de la méthode d’authentification configurée.

6. Si une autre méthode d’authentification est requise conformément à la stratégie de ressource ou à la stratégie d’authentification globale, AD FS déclenche l’authentification supplémentaire.

7. AD FS utilise l’authentification multifacteur Microsoft Entra ou l’authentification multifacteur tierce pour effectuer l’authentification.

8. Une fois l’utilisateur authentifié, AD FS applique les règles de revendication. Les règles de revendication déterminent les revendications envoyées à la ressource dans le cadre des jetons de sécurité. AD FS applique également les stratégies de contrôle d’accès qui confirment que l’utilisateur répond aux conditions requises pour accéder à la ressource.

9. Ensuite, AD FS génère l’accès et actualise les jetons. AD FS génère également le jeton d’ID.

10. AD FS reçoit la demande d’authentification.

11. Si vous incluez le scope = allatclaims dans la demande d’authentification, cela personnalise le jeton d’ID pour inclure des réclamations dans le jeton d’accès, conformément aux règles de réclamation définies.

12. Une fois les jetons requis générés et personnalisés, AD FS répond au client et inclut les jetons. La réponse du jeton d’ID est incluse uniquement dans la réponse si la demande d’authentification inclut scope = openid. Le client peut toujours obtenir le jeton ID après l'authentification en utilisant le point de terminaison du jeton.

Types de bibliothèques

Utilisez deux types de bibliothèques avec AD FS :

• Bibliothèques clientes : les clients natifs et les applications serveur utilisent des bibliothèques clientes pour obtenir des jetons d’accès pour appeler une ressource telle qu’une API web. Microsoft Authentication Library (MSAL) est la bibliothèque cliente la plus récente et recommandée lorsque vous utilisez AD FS 2019.

• Bibliothèques d’intergiciels serveur : les applications web utilisent des bibliothèques d’intergiciels serveur pour la connexion utilisateur. Les API web utilisent des bibliothèques d’intergiciels serveur pour valider les jetons envoyés par des clients natifs ou par d’autres serveurs. Open Web Interface for .NET (OWIN) est la bibliothèque d’intergiciels recommandée.

Personnaliser le jeton ID (revendications supplémentaires dans le jeton ID)

Dans certains scénarios, il est possible que le client d’application web a besoin de revendications supplémentaires dans un jeton d’ID pour faciliter la fonctionnalité. Configurez des revendications supplémentaires dans un jeton d’ID à l’aide de l’une des options suivantes :

Option 1 : Utilisez cette option lorsque vous avez un client public et que l’application web n’a pas de ressource à laquelle il tente d’accéder. Cette option requiert :

• response_mode est défini en tant que form_post
• L’identificateur de partie de confiance (identificateur d’API web) est identique à l’identificateur client

Option 2 : Utilisez cette option lorsque l’application web a une ressource qu’elle tente d’accéder et doit transmettre des revendications supplémentaires via le jeton d’ID. Vous pouvez utiliser des clients publics et confidentiels. Cette option requiert :

• response_mode est défini en tant que form_post

• KB4019472 est installé sur vos serveurs AD FS

• L'étendue allatclaims est attribuée à la paire client-RP. Vous pouvez affecter l’étendue à l’aide du Grant-ADFSApplicationPermission. Utilisez cette option Set-AdfsApplicationPermission si elle a déjà été accordée une fois. L’applet de commande PowerShell est indiquée dans l’exemple suivant :

  Grant-AdfsApplicationPermission -ClientRoleIdentifier "https://my/privateclient" -ServerRoleIdentifier "https://rp/fedpassive" -ScopeNames "allatclaims","openid"
  

Pour mieux comprendre comment configurer une application web dans AD FS pour obtenir un jeton d’ID personnalisé, consultez les jetons d’ID personnalisés dans AD FS 2016 ou version ultérieure.

Déconnexion unique

La déconnexion unique met fin à toutes les sessions client qui utilisent l'ID de session. AD FS 2016 et versions ultérieures prend en charge la déconnexion unique pour OpenID Connect/OAuth. Pour plus d'informations, consultez Déconnexion unique pour OpenID Connect avec AD FS.

Points de terminaison AD FS

Point de terminaison AD FS	Descriptif
/autoriser	AD FS retourne un code d’autorisation que vous pouvez utiliser pour obtenir le jeton d’accès.
/token	AD FS retourne un jeton d’accès que vous pouvez utiliser pour accéder à la ressource, comme dans l’API web.
/userinfo	AD FS renvoie l'objet de la demande.
/devicecode	AD FS retourne le code de l’appareil et le code utilisateur.
/logout	AD FS déconnecte l’utilisateur.
/clés	Clés publiques AD FS utilisées pour signer des réponses.
/.well-known/openid-configuration	AD FS retourne les métadonnées OAuth/OpenID Connect.