Gestion des jetons pour Confiance Zéro

  • Article

Dans le cadre du développement d'applications Confiance Zéro, il est important de définir spécifiquement l’intention de votre application et ses exigences d’accès aux ressources. Votre application doit demander uniquement l’accès dont elle a besoin pour fonctionner comme prévu. Cet article vous aide, en tant que développeur, à créer une sécurité dans vos applications avec des jetons d’ID, des jetons d’accès et des jetons de sécurité que votre application peut recevoir à partir de la Plateforme d’identités Microsoft.

Assurez-vous que votre application respecte le principe de Confiance Zéro de privilège minimum et empêche l’utilisation de manière à compromettre votre intention. Limitez l'accès utilisateur avec l'accès juste-à-temps et juste suffisant (JIT/JEA), des stratégies adaptatives basées sur les risques et une protection des données. Séparez les sections sensibles et puissantes de votre application, qui fournissent uniquement un accès utilisateur autorisé à ces zones. Limitez les utilisateurs qui peuvent utiliser votre application et les fonctionnalités qu’ils possèdent dans votre application.

Générez le privilège minimum dans la façon dont votre application gère les jetons d’ID qu’elle reçoit de la Plateforme d'identités Microsoft. Les informations contenues dans les jetons d'ID vous permettent de vérifier qu'un utilisateur est bien celui qu'il prétend être. L’utilisateur ou son organisation peut spécifier des conditions d’authentification telles que la fourniture d’une MFA, l’utilisation d’un appareil géré et l’emplacement approprié.

Facilitez la gestion des autorisations à votre application par vos clients. Réduisez la surcharge de provisionnement de l’utilisateur et la nécessité de processus manuels. L’approvisionnement automatique d’utilisateurs permet aux administrateurs informatiques d’automatiser la création, la maintenance et la suppression des identités utilisateur dans les magasins d’identités cibles. Vos clients peuvent baser des automatisations sur les modifications apportées aux utilisateurs et aux groupes avec l’approvisionnement d’applications ou l’approvisionnement piloté par les ressources humaines dans Microsoft Entra ID.

Utilisation des revendications de jeton dans vos applications

Utilisez les réclamations dans les jetons d'identification pour l'interface utilisateur au sein de votre application, comme clés dans une base de données et pour fournir un accès à l'application client. Le jeton d'ID est l'extension principale qu'OpenID Connect apporte à OAuth 2.0. Votre application peut recevoir des jetons d’ID parallèlement ou au lieu de jetons d’accès.

Dans le modèle standard d’autorisation de jeton de sécurité, un jeton d’ID émis permet à l’application de recevoir des informations sur l’utilisateur. N’utilisez pas le jeton d’ID comme processus d’autorisation pour accéder aux ressources. Le serveur d'autorisation émet des jetons d'identification qui contiennent des réclamations avec des informations sur l'utilisateur, dont les suivantes.

  • La revendication d’audience (aud) est l’ID client de votre application. Acceptez uniquement les jetons pour votre ID client d’API.
  • La revendicationtid est l’ID du client qui a émis le jeton. La oid revendication est une valeur immuable qui identifie de façon unique l’utilisateur. Utiliser la combinaison unique des revendications tid et oid en tant que clé lorsque vous devez associer des données à l’utilisateur. Vous pouvez utiliser ces valeurs de revendication pour reconnecter vos données à l’ID de l’utilisateur dans Microsoft Entra ID.
  • La sub revendication est une valeur immuable qui identité de manière unique l’utilisateur. La revendication d’objet est également unique pour votre application. Si vous utilisez la sub revendication pour associer des données à l’utilisateur, il est impossible de partir de vos données et de le connecter à un utilisateur dans Microsoft Entra ID..

Vos applications peuvent utiliser l’étendue openid pour demander un jeton d’ID à partir du Plateforme d'identités Microsoft. La norme OIDC régit l’étendue openid ainsi que le format et le contenu du jeton d’ID. OIDC spécifie ces étendues :

  • Utilisez l’étendue openid pour connecter l’utilisateur et ajouter une sub revendication au jeton d’ID. Ces étendues fournissent un ID d’utilisateur unique à l’application et à l’utilisateur et appelle le point de terminaison UserInfo.
  • emailL’étendue ajoute une revendication email contenant l’adresse e-mail de l’utilisateur au jeton d’ID.
  • L’étendue profile ajoute des revendications avec des attributs de profil de base de l’utilisateur (nom, nom d’utilisateur) au jeton d’ID.
  • L’étendue offline_access permet à l’application d’accéder aux données utilisateur même si l’utilisateur n’est pas présent.

La bibliothèque Microsoft Authenticator (MSAL) ajoute toujours l’openid, l’email et profile les étendues à chaque demande de jeton. Par conséquent, MSAL retourne toujours un jeton d’ID et un jeton d’accès sur chaque appel à AcquireTokenSilent ou AcquireTokenInteractive. MSAL demande toujours l’étendue offline_access . Le Plateforme d'identités Microsoft retourne offline_access toujours l’étendue même lorsque l’application demandée ne spécifie pas l’étendueoffline_access.

Microsoft utilise la norme OAuth2 pour émettre des jetons d’accès. La norme OAuth2 indique que vous recevez un jeton, mais qu’il ne spécifie pas le format de jeton ou ce qui doit être dans le jeton. Lorsque votre application doit accéder à une ressource que Microsoft Entra ID protège, elle doit utiliser une étendue définie par la ressource.

Par exemple, Microsoft Graph définit l’étendue User.Read qui autorise l’application à accéder au profil utilisateur complet de l’utilisateur actuel et au nom du client. Microsoft Graph définit des autorisations sur toute la gamme de fonctionnalités disponibles dans cette API.

Lors de l’autorisation, le Plateforme d'identités Microsoft retourne un jeton d’accès à votre application. Lorsque vous appelez la ressource, votre application fournit ce jeton dans le cadre de l’en-tête d’autorisation de la requête HTTP à l’API.

Gestion des durées de vie des jetons

Les applications peuvent créer une session pour un utilisateur une fois l’authentification terminée avec Microsoft Entra ID. La gestion des sessions utilisateur détermine la fréquence à laquelle un utilisateur a besoin d’une réauthentification. Son rôle dans la conservation d’un utilisateur vérifié explicitement devant l’application avec le privilège approprié et pour la bonne durée est crucial. La durée de vie de la session doit être basée sur la exp revendication dans le jeton d’ID. La exp revendication est l’heure à laquelle le jeton d’ID expire et l’heure après laquelle vous ne pouvez plus utiliser le jeton pour authentifier l’utilisateur.

Respectez toujours la durée de vie du jeton comme indiqué dans la réponse du jeton pour les jetons d’accès ou la exp revendication dans le jeton d’ID. Les conditions qui régissent la durée de vie des jetons peuvent inclure la fréquence de connexion pour une entreprise. Votre application ne peut pas configurer la durée de vie du jeton. Vous ne pouvez pas demander de durée de vie de jeton.

En général, les jetons doivent être valides et non expirés. La revendication d’audience (aud) doit correspondre à votre ID client. Vérifiez que le jeton provient d’un émetteur approuvé. Si vous disposez d’une API mutualisée, vous pouvez choisir de filtrer afin que seuls des clients spécifiques puissent appeler votre API. Veillez à appliquer la durée de vie du jeton. Vérifiez les revendications nbf (non antérieures) et exp (expiration) pour vous assurer que l’heure actuelle se trouve dans les valeurs de ces deux revendications.

Ne visez pas des durées de vie exceptionnellement longues ou courtes. Laissez la durée de vie du jeton d’ID accordée conduire cette décision. La conservation des sessions de votre application active au-delà de la validité des jetons enfreint les règles, les stratégies et les préoccupations qui ont conduit un administrateur informatique à définir une durée de validité de jeton pour empêcher l’accès non autorisé. Les sessions courtes dégradent l’expérience utilisateur et n’augmentent pas nécessairement la posture de sécurité. Les cadres populaires tels que ASP.NET vous permettent de définir des délais d’expiration de session et de cookie à partir de l’heure d’expiration du jeton d’ID de Microsoft Entra ID. Le suivi du délai d’expiration du jeton du fournisseur d’identité garantit que les sessions de votre utilisateur ne sont jamais plus longues que les stratégies dictées par le fournisseur d’identité.

Mise en cache et jeton d'actualisation

N’oubliez pas de mettre en cache correctement les jetons. MSAL met automatiquement en cache les jetons, mais les jetons ont des durées de vie. Utilisez des jetons par le biais de la durée de vie complète de leurs durées de vie et mettez-les en cache correctement. Si vous demandez à plusieurs reprises le même jeton, la limitation entraîne la réactivité de votre application. Si votre application abuse de l’émission de jetons, le temps nécessaire pour émettre de nouveaux jetons à votre application s’allonge.

Les bibliothèques MSAL gèrent les détails du protocole OAuth2, notamment la mécanique de l’actualisation des jetons. Si vous n’utilisez pas MSAL, assurez-vous que votre bibliothèque de choix utilise efficacement les jetons d’actualisation.

Lorsque votre client acquiert un jeton d'accès pour accéder à une ressource protégée, il reçoit un jeton d’actualisation. Utilisez le jeton de rafraîchissement pour obtenir de nouvelles paires de jetons d'accès/de rafraîchissement après l'expiration du jeton d'accès actuel. Utiliser les jetons de rafraîchissement pour acquérir des jetons d'accès supplémentaires pour d'autres ressources. Les jetons d’actualisation sont associés à une combinaison utilisateur/client, mais ils ne sont pas liés à une ressource ou à un client. Vous pouvez utiliser un jeton de rafraîchissement pour acquérir des jetons d'accès pour toute combinaison de ressources et de locataires pour lesquels votre application dispose de permissions.

Gestion des erreurs de jeton et des bogues

Votre application ne doit jamais tenter de valider, décoder, inspecter, interpréter ou examiner le contenu d’un jeton d’accès. Ces opérations sont strictement responsables de l’API de ressource. Si votre application tente d’examiner le contenu d’un jeton d’accès, il est très probable que votre application s’interrompt lorsque le Plateforme d'identités Microsoft émet des jetons chiffrés.

Dans de rares cas, un appel pour récupérer un jeton peut échouer en raison de problèmes tels qu'une panne ou une interruption du réseau, de l'infrastructure ou du service d'authentification. Augmentez la résilience de l’expérience d’authentification dans votre application si un échec d’acquisition de jeton se produit en suivant les bonnes pratiques suivantes :

  • Mettre en cache localement et sécuriser des jetons avec chiffrement.
  • Ne transmettez pas d’artefacts de sécurité tels que des jetons sur des canaux non sécurisés.
  • Comprendre et agir sur les exceptions et les réponses de service du fournisseur d’identité.

Les développeurs ont souvent des questions sur la recherche dans les jetons pour déboguer des problèmes tels que la réception d’une erreur 401 lors de l’appel de la ressource. Comme des jetons plus chiffrés vous empêchent d’examiner à l’intérieur d’un jeton d’accès, vous devez trouver des alternatives à la recherche dans les jetons d’accès. Pour le débogage, la réponse du jeton qui contient le jeton d’accès fournit les informations dont vous avez besoin.

Dans votre code, case activée pour les classes d’erreur plutôt que pour les cas d’erreur individuels. Par exemple, gérez l’interaction utilisateur requise plutôt que les erreurs individuelles où le système n’a pas accordé l’autorisation. Étant donné que vous pouvez manquer ces cas individuels, il est préférable de case activée pour un classifieur comme l’interaction utilisateur plutôt que d’explorer des codes d’erreur individuels.

Vous devrez peut-être revenir à AcquireTokenInteractive la demande et fournir des défis en matière de revendications dont l’appel AcquireTokenSilent a besoin. Cela garantit une gestion efficace de la demande interactive.

Étapes suivantes