Présentation du flux d’octroi implicite OAuth2 dans Azure Active Directory (AD)

L'autorisation implicite OAuth2 est réputée pour comporter la plus longue liste de préoccupations en matière de sécurité dans la spécification OAuth2. Et pourtant, c’est l’approche implémentée par ADAL JS et celle que nous recommandons lors de l’écriture d’applications SPA. Qu'est-ce qui se passe ? Il s’agit de compromis : et comme il s’avère, l’octroi implicite est la meilleure approche que vous pouvez poursuivre pour les applications qui consomment une API web via JavaScript à partir d’un navigateur.

Qu’est-ce que l’octroi implicite OAuth2 ?

L’octroi de code d’autorisation OAuth2, qui est essentiel, est l’octroi d’autorisation qui utilise deux points de terminaison distincts. Le point de terminaison d’autorisation est utilisé pour la phase d’interaction utilisateur, ce qui entraîne un code d’autorisation. Le point de terminaison du jeton est alors utilisé par le client pour échanger le code contre un jeton d’accès, souvent également un jeton d’actualisation. Les applications web sont tenues de présenter leurs propres informations d’identification d’application au point de terminaison de jeton, afin que le serveur d’autorisation puisse authentifier le client.

L’octroi implicite OAuth2 est une variante d’autres octrois d’autorisation. Il permet à un client d’obtenir un jeton d’accès (et id_token, lors de l’utilisation d’OpenId Connect) directement à partir du point de terminaison d’autorisation, sans contacter le point de terminaison du jeton ni authentifier le client. Cette variante a été conçue pour les applications JavaScript s’exécutant dans un navigateur Web : dans la spécification OAuth2 d’origine, les jetons sont retournés dans un fragment d’URI. Cela rend les bits de jeton disponibles pour le code JavaScript dans le client, mais il garantit qu’ils ne seront pas inclus dans les redirections vers le serveur. Dans l’octroi implicite OAuth2, le point de terminaison d’autorisation émet des jetons d’accès directement au client à l’aide d’un URI de redirection précédemment fourni. Il présente également l’avantage d’éliminer le besoin d’appels d’origine croisée, qui sont nécessaires si l'application JavaScript doit contacter l'endpoint du jeton.

Une caractéristique importante de l’octroi implicite OAuth2 est le fait que ces flux ne retournent jamais de jetons d’actualisation au client. La section suivante montre comment cela n’est pas nécessaire et serait en fait un problème de sécurité.

Scénarios adaptés à l’octroi implicite OAuth2

La spécification OAuth2 déclare que l’octroi implicite a été conçu pour permettre aux applications de l’agent utilisateur , c’est-à-dire les applications JavaScript s’exécutant dans un navigateur. La caractéristique de définition de ces applications est que le code JavaScript est utilisé pour accéder aux ressources du serveur (généralement une API web) et pour mettre à jour l’expérience utilisateur de l’application en conséquence. Pensez aux applications telles que Gmail ou Outlook Web Access : lorsque vous sélectionnez un message dans votre boîte de réception, seul le panneau de visualisation des messages change pour afficher la nouvelle sélection, tandis que le reste de la page reste inchangé. Cette caractéristique est différente des applications web traditionnelles basées sur la redirection, où chaque interaction utilisateur entraîne une publication de page complète et un rendu de page complet de la nouvelle réponse du serveur.

Les applications qui poussent l’approche basée sur JavaScript à l'extrême sont appelées applications monopage ou SPAs. L’idée est que ces applications servent uniquement une page HTML initiale et javaScript associée, avec toutes les interactions suivantes pilotées par les appels d’API web effectués via JavaScript. Toutefois, les approches hybrides, où l’application est principalement pilotée par postback, mais effectue des appels JS occasionnels, ne sont pas rares : la discussion sur l’utilisation implicite des flux est également pertinente pour celles-ci.

Les applications basées sur une redirection sécurisent généralement leurs demandes via des cookies, mais cette approche ne fonctionne pas aussi bien pour les applications JavaScript. Les cookies fonctionnent uniquement sur le domaine pour lequel ils ont été générés, tandis que les appels JavaScript peuvent être dirigés vers d’autres domaines. En fait, cela sera souvent le cas : pensez aux applications appelant l’API Microsoft Graph, l’API Office, l’API Azure , tous résidant en dehors du domaine à partir duquel l’application est servie. Une tendance croissante pour les applications JavaScript consiste à n’avoir aucun back-end du tout, en s’appuyant sur 100% sur des API web tierces pour implémenter leur fonction métier.

Actuellement, la méthode préférée de protection des appels à une API web consiste à utiliser l’approche du jeton du porteur OAuth2, où chaque appel est accompagné d’un jeton d’accès OAuth2. L’API web examine le jeton d’accès entrant et, si elle trouve dans elle les étendues nécessaires, elle accorde l’accès à l’opération demandée. Le flux implicite fournit un mécanisme pratique pour les applications JavaScript afin d’obtenir des jetons d’accès pour une API web, offrant de nombreux avantages en ce qui concerne les cookies :

• Les jetons peuvent être obtenus de manière fiable sans avoir besoin d’appels d’origine croisée : inscription obligatoire de l’URI de redirection vers laquelle les jetons sont retournés garantit que les jetons ne sont pas déplacés
• Les applications JavaScript peuvent obtenir autant de jetons d’accès que nécessaire, pour autant d’API web qu’elles ciblent – sans restriction sur les domaines
• Les fonctionnalités HTML5 telles que la session ou le stockage local accordent un contrôle total sur la mise en cache des jetons et la gestion de la durée de vie, tandis que la gestion des cookies est opaque pour l’application
• Les jetons d’accès ne sont pas sensibles aux attaques par falsification de requête intersite (CSRF)

Le flux d’octroi implicite n’émet pas de jetons d’actualisation, principalement pour des raisons de sécurité. Un jeton d'actualisation n'est pas aussi spécifiquement défini que les jetons d'accès, ce qui lui confère beaucoup plus de droits et donc peut causer beaucoup plus de dommages s'il venait à être compromis. Dans le flux implicite, les jetons sont transmis via l'URL, d'où un risque d'interception plus élevé que dans le cadre de l'octroi d'un code d'autorisation.

Toutefois, une application JavaScript dispose d’un autre mécanisme à sa disposition pour renouveler les jetons d’accès sans inviter l’utilisateur à entrer des informations d’identification à plusieurs reprises. L’application peut utiliser un iframe masqué pour effectuer de nouvelles demandes de jetons sur le point de terminaison d’autorisation d’Azure AD : tant que le navigateur dispose toujours d’une session active (lecture : dispose d’un cookie de session) sur le domaine Azure AD, la demande d’authentification peut se produire sans avoir besoin d’interaction utilisateur.

Ce modèle accorde à l’application JavaScript la possibilité de renouveler indépendamment les jetons d’accès et même d’en acquérir de nouveaux pour une nouvelle API (à condition que l’utilisateur ait précédemment accepté pour eux). Cela évite la charge ajoutée de l’acquisition, de la maintenance et de la protection d’un artefact à valeur élevée, comme un jeton d’actualisation. L’artefact qui rend le renouvellement silencieux possible, le cookie de session Azure AD, est géré en dehors de l’application. Un autre avantage de cette approche est qu’un utilisateur peut se déconnecter d’Azure AD, à l’aide de l’une des applications connectées à Azure AD, s’exécutant dans l’un des onglets du navigateur. Cela entraîne la suppression du cookie de session Azure AD, et l’application JavaScript perd automatiquement la possibilité de renouveler des jetons pour l’utilisateur déconnecté.

L’octroi implicite convient-il à mon application ?

L'autorisation implicite présente plus de risques que d'autres autorisations, et les domaines auxquels vous devez prêter attention sont bien documentés (par exemple, utilisation abusive du jeton d’accès pour usurper l'identité du propriétaire de la ressource dans le flux implicite et modèle de menace OAuth 2.0 et considérations de sécurité). Toutefois, le profil à risque plus élevé est principalement dû au fait qu’il est destiné à permettre aux applications qui exécutent du code actif, servies par une ressource distante à un navigateur. Si vous planifiez une architecture SPA, n’avez aucun composant principal ou envisagez d’appeler une API web via JavaScript, l’utilisation du flux implicite pour l’acquisition de jetons est recommandée.

Si votre application est un client natif, le flux implicite n’est pas adapté. L’absence du cookie de session Azure AD dans le contexte d’un client natif prive votre application des moyens de maintenir une session de longue durée. Cela signifie que votre application invite à plusieurs reprises l’utilisateur lors de l’obtention de jetons d’accès pour de nouvelles ressources.

Si vous développez une application web qui inclut un back-end et que vous consommez une API à partir de son code principal, le flux implicite n’est pas non plus adapté. D’autres subventions vous donnent beaucoup plus de pouvoir. Par exemple, l’octroi d’informations d’identification du client OAuth2 permet d’obtenir des jetons qui reflètent les autorisations affectées à l’application elle-même, par opposition aux délégations d’utilisateurs. Cela signifie que le client a la possibilité de maintenir l’accès programmatique aux ressources même lorsqu’un utilisateur n’est pas activement engagé dans une session, et ainsi de suite. Non seulement cela, mais ces subventions offrent des garanties de sécurité plus élevées. Par exemple, les jetons d’accès ne transitent jamais par le navigateur utilisateur, ils ne risquent pas d’être enregistrés dans l’historique du navigateur, et ainsi de suite. L’application cliente peut également effectuer une authentification forte lors de la demande d’un jeton.

Étapes suivantes

• Découvrez comment intégrer une application à Azure AD pour obtenir une profondeur supplémentaire sur le processus d’intégration de l’application.