Partager via

Développer une stratégie d’autorisations déléguées

  • Article

Cet article vous aide, en tant que développeur, à implémenter la meilleure approche pour gérer les autorisations dans votre application et à développer du code selon les principes de la Confiance Zéro. Comme décrit dans Acquérir l’autorisation d’accéder aux ressources, les autorisations déléguées sont utilisées avec un accès délégué pour permettre à une application d’agir au nom d’un utilisateur, en accédant uniquement à ce que l’utilisateur peut accéder. Les autorisations d’application sont utilisées avec un accès direct pour permettre à une application d’accéder à toutes les données auxquelles l’autorisation est associée. Seul un administrateur ou un propriétaire du principal de service peut donner son consentement aux autorisations d’application.

Les modèles d’autorisation et de consentement font principalement référence à une application. Le processus d’autorisation et de consentement n’a aucun contrôle sur ce qu’un utilisateur peut faire. Elle contrôle les actions que l’application est autorisée à effectuer.

Référencez le diagramme de Venn suivant. Avec les permissions déléguées, il existe une intersection entre ce que l’utilisateur est autorisé à faire et ce que l’application est autorisée à faire. Cette intersection est l’autorisation effective par laquelle l’application est liée. Chaque fois que vous utilisez une autorisation déléguée, les autorisations effectives la lient.

Le diagramme de Venn montre que les autorisations effectives sont à l’intersection des autorisations de l’application et des capacités de l’utilisateur(-trice).

Par exemple, votre application qui a des utilisateurs devant l’application obtient l’autorisation de mettre à jour le profil de chaque utilisateur dans le locataire. Cela ne signifie pas que toute personne exécutant votre application peut mettre à jour le profil d’une autre personne. Si l’administrateur décide d’accorder votre application User.ReadWrite.All, il croit que votre application fait les bonnes choses lors de la mise à jour d’un profil d’utilisateur. Votre application peut enregistrer les modifications et protéger correctement les informations. L’administrateur fait un jugement de valeur sur l’application, et non sur l’utilisateur.

Approche des privilèges minimum

Les API peuvent être complexe. Il est possible que des API simples n’aient pas plusieurs opérations. Les API complexes telles que Microsoft Graph encapsulent plusieurs requêtes qu’une application peut utiliser. Simplement parce que l’application a le droit de lire ne signifie pas qu’elle doit avoir le droit de mettre à jour. Par exemple, Microsoft Graph a des milliers d’API. Simplement parce que vous avez l’autorisation de lire le profil de utilisateurs, il n’y a aucune raison pour laquelle vous devez également avoir l’autorisation de supprimer tous leurs fichiers OneDrive.

En tant que développeur, vous devez :

  • connaître les API que l’application appelle.
  • comprendre la documentation de l’API et les autorisations requises par l’API.
  • utilisez la moindre autorisation possible pour accomplir vos tâches.

Les API fournissent souvent l’accès aux magasins de données de l’organisation et attirent l’attention des attaquants qui souhaitent accéder à ces données.

Évaluez les autorisations que vous demandez pour vous assurer de rechercher le jeu le moins privilégié absolu pour accomplir la tâche. Évitez de demander des autorisations de privilège plus élevées ; Au lieu de cela, utilisez soigneusement le grand nombre d’autorisations que fournissent les API comme Microsoft Graph. Recherchez et utilisez les autorisations minimales pour répondre à vos besoins. Si vous n’écrivez aucun code pour mettre à jour le profil d’utilisateur, vous ne le demandez pas pour votre application. Si vous accédez uniquement à des utilisateurs et des groupes, vous ne demandez pas l’accès aux autres informations du répertoire. Vous ne demandez pas l’autorisation de gérer l’adresse e-mail d’un utilisateur si vous n’écrivez aucun code qui accède à l’adresse e-mail de l’utilisateur.

Dans le cadre du développement d'applications Confiance Zéro :

  • Définir l’intention de votre application et ce dont elle a besoin.
  • Assurez-vous que les acteurs incorrects ne peuvent pas compromettre et utiliser votre application d’une manière que vous n’avez pas l’intention.
  • Effectuez des demandes d’approbation dans lesquelles vous définissez vos exigences (par exemple, lisez le courrier de l’utilisateur).

Personnes qui peut approuver vos demandes se répartissent en deux catégories : les administrateurs qui peuvent toujours consentir aux demandes d’autorisation et aux utilisateurs réguliers qui ne sont pas administrateurs. Toutefois, les administrateurs de clients ont le dernier mot dans leur locataire concernant les autorisations qui nécessitent le consentement administrateur et les autorisations auxquelles un utilisateur peut donner son consentement.

Quand un concepteur d’API nécessite un consentement administrateur pour une autorisation, cette dernière exige toujours un consentement administrateur. Un administrateur de locataire ne peut pas le remplacer et exiger uniquement un consentement de l’utilisateur.

Quand un concepteur d’API définit des autorisations qui nécessitent un consentement de l’utilisateur, l’administrateur de locataire peut remplacer les suggestions de consentement de l’utilisateur du concepteur de l’API. Les administrateurs de locataire peuvent l’effectuer avec un « grand changement » dans le tenant : tout nécessite un consentement administrateur. Ils peuvent remplacer le consentement de l’utilisateur de manière plus granulaire avec l’autorisation et la gestion des consentements. Par exemple, il est possible qu’ils autorisent des utilisateurs à consentir aux demandes de consentement de l’utilisateur à partir d’éditeurs vérifiés, mais pas à partir des autres. Dans un autre exemple, il est possible qu’ils autorisent User.Read à se connecter à l’utilisateur et lire son profil, mais exigent un consentement administrateur pour des applications qui demandent une autorisation afin d’accéder au courrier ou aux fichiers.

Les concepteurs d’API font leurs suggestions, mais les admins client ont le dernier mot. Par conséquent, en tant que développeur, vous ne savez pas toujours quand votre application nécessite un consentement administrateur. Il est agréable de planifier et de concevoir autour de cela, mais rappelez-vous, quand vous effectuez une demande de jeton, il peut être refusé pour une raison quelconque. Dans votre code, vous devez gérer correctement l’obtention d’un jeton, car les admins client dans lesquels vos clients ou utilisateurs exécutent votre application décident quand les autorisations nécessitent le consentement administrateur.

Exemple d’utilisation de MSAL JavaScript

Pour l’authentification dans cet exemple, vous utilisez notre Bibliothèque d’authentification Microsoft (MSAL) JavaScript pour connecter l’utilisateur dans une application monopage (SPA) où toute la logique d’application s’exécute à partir du navigateur.

Dans l’article de démarrage rapide associé, vous pouvez télécharger et exécuter un exemple de code. Il montre comment une application monopage JavaScript (SPA) peut connecter des utilisateurs et appeler Microsoft Graph en utilisant le flux de code d'autorisation avec la clé de preuve pour l'échange de code (PKCE). L’exemple de code montre comment obtenir un jeton d’accès pour appeler l’API Microsoft Graph ou n’importe quelle API web.

Comme illustré dans l’exemple de code suivant, vous instanciez un client public, car une application s’exécutant complètement dans le navigateur doit être un client public. L’utilisateur peut se familiariser avec les éléments internes de votre application lorsque le code se trouve dans le navigateur.

// Create the main myMSALObj instance
// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication(msalConfig);

Vous utilisez ensuite notre bibliothèque MSAL. Dans MSAL JavaScript, il existe une API spécifique à connecter. Il existe deux API qui utilisent des fonctionnalités spécifiques dans le navigateur. L’une consiste à se connecter avec une expérience contextuelle ; l’autre consiste à se connecter avec une expérience de redirection de navigateur.

Comme montré dans l’exemple de code suivant, la fenêtre contextuelle de connexion gère l’authentification que l’utilisateur doit effectuer en appelant la fonction signIn.

function signIn() {

    /**
     * You can pass a custom request object. This overrides the initial configuration. For more information, visit:
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/request-response-object.md#request
     */

    myMSALObj.loginPopup(loginRequest)
        .then(handleResponse)
        .catch(error => {
            console.error(error);
        });
}

Votre application peut obtenir des informations sur l’utilisateur, telles que son nom complet ou son identifiant utilisateur. Ensuite, votre application nécessite une autorisation pour lire le profil complet de l’utilisateur à partir de Microsoft Graph en suivant un modèle que vous utilisez dans l’ensemble de nos bibliothèques MSAL.

Comme indiqué dans l’exemple de code ci-dessous, votre application tente d’obtenir l’autorisation en appelant AcquireTokenSilent. Si Microsoft Entra ID peut émettre le jeton sans interagir avec l’utilisateur, AcquireTokenSilent retourne alors le jeton dont votre application a besoin pour accéder à Microsoft Graph au nom de l’utilisateur.

function getTokenPopup(request) {

    /**
     * See here for more info on account retrieval: 
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-common/docs/Accounts.md
     */
    request.account = myMSALObj.getAccountByUsername(username);
    
    return myMSALObj.`AcquireTokenSilent`(request)
        .catch(error => {
            console.warn("silent token acquisition fails. acquiring token using popup");
            if (error instanceof msal.InteractionRequiredAuthError) {
                // fallback to interaction when silent call fails
                return myMSALObj.`AcquireTokenPopup`(request)
                    .then(tokenResponse => {
                        console.log(tokenResponse);
                        return tokenResponse;
                    }).catch(error => {
                        console.error(error);
                    });
            } else {
                console.warn(error);
            }
    });
}

Toutefois, Microsoft Entra ID est souvent dans l’impossibilité d’émettre le jeton sans interagir avec l’utilisateur (par exemple, l’utilisateur a modifié son mot de passe ou ne donne pas son consentement). Par conséquent, AcquireTokenSilent renvoie une erreur à l’application qui nécessite une interaction de l’utilisateur. Quand votre application reçoit l’erreur, vous revenez pour appeler AcquireTokenPopup.

À ce stade, Microsoft Entra ID a une conversation avec l’utilisateur afin qu’il puisse l’authentifier et autoriser votre application à agir au nom de l’utilisateur (par exemple, effectuer une authentification multifacteur, fournir son mot de passe, donner son consentement). Votre application obtient ensuite le jeton dont elle a besoin pour continuer.

Une étape principale dans le parcours d’une entreprise vers Confiance Zéro consiste à adopter des méthodes d’authentification plus fortes au lieu d’un identifiant utilisateur et d’un mot de passe. L’exemple de code précédent permet à une entreprise de passer à une méthode d’authentification plus forte qu’elle choisit. Par exemple, l’authentification multifacteur, sans mot de passe avec une clé FIDO2, Microsoft Authenticator.

Étapes suivantes