Concepts AD FS OpenID Connect/OAuth

Article
06/09/2023
S’applique à:

✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

S’applique AD FS 2016 et aux versions ultérieures

Acteurs modernes de l’authentification

Acteur	Description
Utilisateur final	Le mandataire de sécurité (utilisateurs, applications, services et groupes) qui accède à la ressource.
Client	Votre application web, identifiée par son ID de client. Le client, qui est en général la partie avec laquelle l’utilisateur final interagit, et le client demande des jetons provenant du serveur d’autorisation.
Serveur d’autorisation/Fournisseur d’identité (IdP)	Votre serveur AD FS. Il est chargé de vérifier l’identité des principaux de sécurité qui existent dans l’annuaire d’une organisation. Il émet des jetons de sécurité (jeton d’accès du porteur, jeton d’ID et jeton d’actualisation) en cas d’authentification réussie de ces mandataires de sécurité.
Serveur de ressources/Fournisseur de ressources/Partie de confiance	Lieu où se résident la ressource ou les données. Il approuve le serveur d’autorisation pour authentifier et autoriser de manière sûre le client et utilise les jetons d’accès du porteur pour garantir l’octroi de l’accès à une ressource.

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

Types d’applications

Type d’application	Description	Role
Application native	Parfois appelé client public. Il est destiné à être une application cliente qui s’exécute sur un pc ou sur un appareil et avec laquelle l’utilisateur interagit.	Demande des jetons au serveur d’autorisation (AD FS) pour l’accès utilisateur aux ressources. Envoie les requêtes HTTP aux ressources protégées, en utilisant les jetons en tant qu’en-têtes HTTP.
Application serveur (application web)	Application web qui s’exécute sur un serveur et qui est accessible aux utilisateurs via un navigateur. Étant donné qu’elle est capable de conserver le secret ou les informations d’identification de son propre client, elle est parfois appelée client confidentiel.	Demande des jetons au serveur d’autorisation (AD FS) pour l’accès utilisateur aux ressources. Avant de demander un jeton, le client (application web) doit s’authentifier en utilisant sa clé secrète.
API web	Ressource de terminaison à laquelle l’utilisateur accède. Il s’agit de la nouvelle représentation des parties de confiance.	Consomme les jetons d’accès du porteur obtenus par les clients.

Groupe d’applications

Vous devez associer un groupe d’applications à chaque ressource de client OAuth ou d’API web native ou web configurée avec AD FS. Configurez les clients dans un groupe d’applications pour accéder aux ressources du même groupe. Un groupe d’applications peut avoir plusieurs clients et plusieurs 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 demandes dans le jeton d’ID contiennent des informations sur l’utilisateur afin que le client puisse l’utiliser.
access_token : jeton JWT émis par le serveur d’autorisation (AD FS) et destiné à être consommé par la ressource. La demande « 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 l’utilise lorsqu’il a besoin d’actualiser les id_token et les access_token. Le jeton est opaque pour le client et n’est consommé que par AD FS.

Durées de vie des jetons d’actualisation

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

Pour plus d’informations, consultez la documentation relative à l’authentification unique AD FS.

Portées

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 la configuration de l’étendue, vous devez envoyer la valeur d’étendue dans la requête pour qu’AD FS effectue l’action. Par exemple, un administrateur configure l’étendue en tant que openid pendant l’inscription des ressources et l’application (client) doit envoyer le scope = openid dans la requête d’authentification pour qu’AD FS émette le jeton d’ID. 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 champ refresh_token de la réponse et définit la refresh_token_expires_in field sur la durée de vie du nouveau jeton d’actualisation principal s’il est appliqué.
openid : permet à l’application de demander l’utilisation du protocole d’authentification de connexion openid.
logon_cert : permet à une application de demander des certificats de connexion que vous pouvez utiliser pour connecter de manière interactive des utilisateurs authentifiés. Le serveur AD FS omet le paramètre access_token de la réponse, et fournit à la place 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 de la part d’AD FS. Pour plus d’informations sur l’utilisation de cette étendue, voir Créer une application à plusieurs niveaux avec OBO (On-Behalf-Of) à l’aide d’OAuth avec AD FS 2016 ou version ultérieure.
allatclaims : permet à l’application de demander l’ajout des demandes dans le jeton d’accès au jeton d’ID.
vpn_cert : permet à l’application de demander des certificats VPN qui établissent des connexions VPN en utilisant l’authentification EAP-TLS. Cette fonctionnalité n’est plus prise en charge.
email : permet à l’application de demander une revendication d’e-mail pour l’utilisateur connecté.
profile : permet à une application de demander des revendications relatives au profil pour l’utilisateur connecté.

Revendications

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

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é 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 global

Un diagramme du flux de haut niveau est présenté ci-dessous.

AD FS reçoit une requête d’authentification du client.
AD FS valide l’ID de client dans la requête d’authentification avec l’ID de client obtenu lors de 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 requête d’authentification. AD FS valide également l’URI de redirection du client.
AD FS identifie la ressource à laquelle le client souhaite accéder grâce au paramètre de ressource transmis dans la requête 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 la ressource est envoyée comme partie intégrante du paramètre d’étendue : scope = [url de ressource]/[valeurs d’étendue, par exemple, openid].

Si une ressource n’est pas transmise au moyen de paramètres de ressource ou d’étendue, AD FS utilise une ressource par défaut urn:microsoft:userinfo dont les stratégies, telles que l’authentification multifacteur, l’émission ou l’autorisation, ne peuvent pas être configurées.
Ensuite, AD FS vérifie si le client dispose des autorisations nécessaires pour accéder à la ressource. AD FS valide également si les étendues transmises dans la requête d’authentification correspondent aux étendues configurées lors de l’inscription de la ressource. Si le client ne dispose pas des autorisations ou si les étendues appropriées ne sont pas envoyées dans la requête d’authentification, le flux d’authentification s’arrête.
Une fois les autorisations et les étendues validées, AD FS authentifie l’utilisateur à l’aide de la méthode d’authentification configurée.
Si une autre méthode d’authentification est requise conformément à la stratégie de ressources ou à la stratégie d’authentification globale, AD FS déclenche l’authentification supplémentaire.
AD FS utilise l'authentification multifacteur Microsoft Entra ou l'authentification multifacteur tierce pour effectuer l'authentification.
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 remplit les conditions requises pour accéder à la ressource.
Ensuite, AD FS génère l’accès et actualise les jetons. AD FS génère également le jeton d’ID.
AD FS reçoit la requête d’authentification.
Si vous incluez le scope = allatclaims dans la requête d’authentification, le jeton d’identification est personnalisé pour inclure les revendications dans le jeton d’accès en fonction des règles de revendication définies.
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 n’est incluse dans la réponse que si la requête d’authentification inclut scope = openid. Le client peut toujours obtenir le jeton d’ID après l’authentification à l’aide du point de terminaison du jeton.

Types de bibliothèques

Utilisez deux types de bibliothèques avec AD FS :

Bibliothèques clientes : les applications serveur et les clients natifs utilisent les bibliothèques clientes afin d’obtenir des jetons d’accès pour appeler une ressource, comme une API web. La bibliothèque d’authentification Microsoft (MSAL) est la bibliothèque cliente la plus récente et recommandée lorsque vous utilisez AD FS 2019.
Bibliothèques de middleware de serveur : Les applications web utilisent des bibliothèques de middleware de serveur pour la connexion des utilisateurs. Les API web utilisent des bibliothèques d’intergiciels de 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 d’ID (demandes supplémentaires dans le jeton d’ID)

Dans certains scénarios, il est possible que le client de l’application web ait besoin de demandes supplémentaires dans un jeton d’ID pour faciliter la fonctionnalité. Configurez des demandes 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 la ressource à laquelle elle tente d’accéder. Cette option requiert :

response_mode est défini comme form_post
L’identificateur de partie de confiance (identificateur d’API web) est identique à l’identificateur du client

Diagram of AD FS customize token option one.

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

response_mode est défini comme form_post
KB4019472 est installé sur vos serveurs AD FS
L’étendue allatclaims est attribuée à la paire client – RP. Vous pouvez attribuer l’étendue en utilisant le Grant-ADFSApplicationPermission. Utilisez Set-AdfsApplicationPermission si elle a déjà été accordée une seule fois. L’applet de commande PowerShell est indiqué dans l’exemple suivant :
```
Grant-AdfsApplicationPermission -ClientRoleIdentifier "https://my/privateclient" -ServerRoleIdentifier "https://rp/fedpassive" -ScopeNames "allatclaims","openid"
```

Diagram of AD FS customize token option two.

Pour mieux comprendre comment configurer une application web dans AD FS afin d’obtenir un jeton d’ID personnalisé, consultez 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 clientes 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	Description
/authorize	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 retourne la revendication de l’objet.
/devicecode	AD FS renvoie le code de l’appareil et le code utilisateur.
/logout	AD FS déconnecte l’utilisateur.
/keys	Clés publiques AD FS utilisées pour signer les réponses.
/.well-known/openid-configuration	AD FS renvoie les métadonnées OAuth/OpenID Connect.

Partage via