Partager via

Prise en main des API de gestion d’Office 365

  • Article

Lorsque vous créez une application qui doit accéder à des services sécurisés tels qu’aux API de gestion d’Office 365, vous devez trouver un moyen d’indiquer au service si votre application dispose des droits appropriés pour y accéder. Les API de gestion Office 365 utilisent Microsoft Entra ID pour fournir des services d’authentification que vous pouvez utiliser pour accorder des droits à votre application pour y accéder.

Vous devez suivre quatre étapes principales :

  1. Inscrivez votre application dans Microsoft Entra ID. Pour autoriser votre application à accéder aux API Office 365 Management, vous devez inscrire votre application dans Microsoft Entra ID. Cela vous permet d’établir une identité pour votre application et de spécifier les niveaux d’autorisation dont elle a besoin pour accéder aux API.

  2. Obtenir le consentement de l’administrateur client d’Office 365. Un administrateur client d’Office 365 doit donner explicitement son consentement pour autoriser votre application à accéder à ses données client au moyen des API de gestion d’Office 365. Le processus de consentement est une expérience basée sur un navigateur qui oblige l’administrateur client à se connecter à l’interface utilisateur de consentement Microsoft Entra et à passer en revue les autorisations d’accès demandées par votre application, puis à accorder ou refuser la demande. Une fois le consentement donné, l’interface utilisateur redirige l’utilisateur vers votre application avec un code d’autorisation dans l’URL. Votre application effectue un appel de service à service à Microsoft Entra ID pour échanger ce code d’autorisation contre un jeton d’accès, qui contient des informations sur l’administrateur client et votre application. L’ID client doit être extrait du jeton d’accès et stocké en vue d’une utilisation ultérieure.

  3. Demandez des jetons d’accès à Microsoft Entra ID. À l’aide des informations d’identification de votre application telles que configurées dans Microsoft Entra ID, votre application demande des jetons d’accès supplémentaires pour un locataire ayant donné son consentement en permanence, sans qu’il soit nécessaire d’interagir davantage avec l’administrateur du locataire. Ces jetons d’accès sont appelés jetons d’application uniquement car ils n’incluent pas d’informations sur l’administrateur client.

  4. Appeler les API de gestion d’Office 365. Les jetons d’accès d’application uniquement sont transmis aux API de gestion d’Office 365 pour authentifier et autoriser votre application.

Le diagramme suivant illustre la séquence des demandes de consentement et de jetons d’accès.

Flux d’autorisation de mise en route des API de gestion

Importante

Avant de pouvoir accéder aux données via l’API Activité de gestion Office 365, vous devez activer la journalisation d’audit unifié pour votre organisation Office 365. Pour ce faire, vous devez activer le journal d’audit d’Office 365. Pour obtenir des instructions, consultez la rubrique Activer ou désactiver la recherche dans un journal d’audit Office 365.

L’activation de la journalisation d’audit unifié n’est pas requise si vous utilisez uniquement l’API de communications de service Office 365.

Inscrire votre application dans Microsoft Entra ID

Les API de gestion des Office 365 utilisent Microsoft Entra ID pour fournir une authentification sécurisée à Office 365 données de locataire. Pour accéder aux API de gestion Office 365, vous devez inscrire votre application dans Microsoft Entra ID et, dans le cadre de la configuration, vous devez spécifier les niveaux d’autorisation dont votre application a besoin pour accéder aux API.

Configuration requise

Pour inscrire votre application dans Microsoft Entra ID, vous avez besoin d’un abonnement à Office 365 et d’un abonnement à Azure associé à votre abonnement Office 365. Vous pouvez utiliser des abonnements à la version d’évaluation d’Office 365 et Azure pour commencer. Pour plus d’informations, consultez Bienvenue dans le programme pour les développeurs Office 365.

Utilisez le portail Azure pour inscrire votre application dans Microsoft Entra ID

Une fois que vous disposez d’un locataire Microsoft avec les abonnements appropriés, vous pouvez inscrire votre application dans Microsoft Entra ID.

  1. Connectez-vous au portail Azure, à l'aide des informations d'identification de votre locataire Microsoft disposant de l'abonnement à Office 365 que vous souhaitez utiliser. Vous pouvez également accéder au portail Azure via un lien qui apparaît dans le volet de navigation de gauche du centre d'administration Microsoft 365.

  2. Dans le volet de navigation gauche, sélectionnez Microsoft Entra ID (1).

    Page principale du Portail Azure

  3. Dans la page Microsoft Entra ID, sélectionnez inscriptions d'applications (2), puis Nouvelle inscription (3).

    page inscriptions d'applications dans Microsoft Entra ID

  4. Sur la page Inscriptions d’applications, sélectionnez Nouvelle inscription.

    Une nouvelle page apparaît pour vous permettre de commencer l'enregistrement de votre application.

  5. Sur la page Enregistrer une application, procédez comme suit :

    Processus d'enregistrement de l'application

    1. Nommez votre application.

    2. Choisissez qui peut utiliser l'application et accéder à l'API.

    3. Fournissez une URL de redirection pour la redirection de l'utilisateur après l'authentification, si nécessaire.

  6. Cliquez sur Enregistrer pour enregistrer la nouvelle application.

Configurer les propriétés de votre application dans Microsoft Entra ID

Maintenant que votre application est inscrite, vous devez spécifier plusieurs propriétés importantes qui déterminent le fonctionnement de votre application dans Microsoft Entra ID et la façon dont les administrateurs de locataire accordent leur consentement pour permettre à votre application d’accéder à leurs données à l’aide des API de gestion Office 365.

Pour plus d’informations sur Microsoft Entra configuration d’application en général, consultez Propriétés de l’objet application.

  1. ID CLIENT. Cette valeur est générée automatiquement par Microsoft Entra ID. Votre application utilisera cette valeur lors de la demande de consentement des administrateurs de locataire et lors de la demande de jetons d’application uniquement à Microsoft Entra ID.

  2. L'application est multi-locataire. Cette propriété doit être définie sur OUI pour permettre aux administrateurs clients de donner leur consentement à votre application pour accéder à leurs données à l’aide des API de gestion d’Office 365. Si cette propriété est définie sur NON, votre application pourra accéder uniquement aux données de votre propre client.

  3. URL de réponse. Il s’agit de l’URL vers laquelle un administrateur client sera dirigé après avoir donné son consentement pour autoriser votre application à accéder à ses données à l’aide des API de gestion d’Office 365. Vous pouvez configurer plusieurs URL de réponse selon vos besoins. Azure définit automatiquement la première URL pour qu’elle corresponde à l’URL de connexion que vous avez spécifiée lorsque vous avez créé l’application, mais vous pouvez modifier cette valeur selon vos besoins.

Veillez à choisir Enregistrer après avoir modifié ces propriétés.

Générer une nouvelle clé pour votre application

Les clés, également appelées secrets client, sont utilisées lors de l'échange d'un code d'autorisation contre un jeton d'accès.

  1. Dans la page Microsoft Entra ID du Portail Azure, sélectionnez inscriptions d'applications, puis votre application.

    Sélectionnez l'application que vous venez d'enregistrer

  2. Une fois la page de votre application affichée, sélectionnez Certificats et secrets (1) dans le volet de gauche. Sur cette page, vous pouvez télécharger des certificats et créer de nouveaux secrets clients (2).

    La page Certificats et secrets de l'application

  3. Sur la page Certificats et secrets (1), sélectionnez Nouveau secret client (2), saisissez une description et sélectionnez la durée de votre clé (3), puis sélectionnez Ajouter (4).

    Créer une clé secrète client

  4. Après avoir créé le secret client, la valeur s'affiche sous Secrets client (2). Cliquez sur l'icône du presse-papiers (3) pour copier la valeur secrète du client dans le presse-papiers.

    Copiez la valeur secrète du client dans le presse-papiers et enregistrez-la pour une utilisation ultérieure

    Importante

    Azure affiche uniquement la valeur secrète du client au moment où vous la générez initialement. Vous ne pouvez pas revenir à cette page et récupérer la valeur secrète du client plus tard. Assurez-vous de le copier et de l'enregistrer dans un emplacement sécurisé afin de pouvoir l'utiliser plus tard.

Configurer un certificat X.509 pour activer les appels de service à service

Une application qui est en cours d’exécution en arrière-plan, comme un démon ou un service, peut utiliser les informations d’identification client pour demander des jetons d’accès d’application uniquement sans demander plusieurs fois le consentement à l’administrateur client une fois que le consentement initial a été donné.

Pour plus d’informations, consultez la rubrique relative aux appels de service à service à l’aide des informations d’identification client.

Vous devez configurer un certificat X.509 avec votre application pour qu’il soit utilisé comme informations d’identification client lors de la demande de jetons d’accès d’application uniquement à partir de Microsoft Entra ID. Le processus se déroule en deux étapes :

  • Obtenir un certificat X.509. Vous pouvez utiliser un certificat auto-signé ou un certificat émis par une autorité de certification approuvée publiquement.

  • Modifier votre manifeste d’application pour inclure l’empreinte et la clé publique de votre certificat.

Les instructions suivantes montrent comment utiliser l’outil makecert du Kit de développement logiciel (SDK) Windows ou Visual Studio pour générer un certificat auto-signé et exporter la clé publique dans un fichier codé en base 64.

  1. Dans la ligne de commande, exécutez la commande suivante :

     makecert -r -pe -n "CN=MyCompanyName MyAppName Cert" -b 03/15/2015 -e 03/15/2017 -ss my -len 2048

    Remarque

    Lorsque vous générez le certificat X.509, vérifiez que la longueur minimale de la clé est 2048. Les raccourcis clavier ne sont pas acceptés en tant que clés valides.

  2. Ouvrez le composant logiciel enfichable Certificats MMC et connectez-vous à votre compte d’utilisateur.

  3. Recherchez le nouveau certificat dans le dossier Personnel et exportez la clé publique vers un fichier codé en base64 (par exemple, mycompanyname.cer). Votre application utilisera ce certificat pour communiquer avec Microsoft Entra ID. Veillez donc à conserver également l’accès à la clé privée.

    Remarque

    Vous pouvez utiliser Windows PowerShell pour extraire l’empreinte et la clé publique codée en base 64. D’autres plateformes fournissent des outils similaires pour récupérer les propriétés des certificats.

  4. À partir d’une invite Windows PowerShell, entrez et exécutez les commandes suivantes :

     $cer = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
 $cer.Import("mycer.cer")
 $bin = $cer.GetRawCertData()
 $base64Value = [System.Convert]::ToBase64String($bin)
 $bin = $cer.GetCertHash()
 $base64Thumbprint = [System.Convert]::ToBase64String($bin)
 $keyid = [System.Guid]::NewGuid().ToString()

  5. Stockez les valeurs pour $base64Thumbprint, $base64Value et $keyid à utiliser lorsque vous mettez à jour le manifeste de votre application dans les étapes suivantes.

    À l’aide des valeurs extraites du certificat et de l’ID de clé généré, vous devez maintenant mettre à jour le manifeste de votre application dans Microsoft Entra ID.

  6. Dans le portail Azure, accédez à Inscriptions d'applications> Toutes les applications, sélectionnez votre application, puis sélectionnez Manifeste dans le volet gauche.

  7. Dans la barre de navigation supérieure de la page Manifeste (1), sélectionnez Télécharger (2).

    Téléchargez le manifeste pour pouvoir le modifier

  8. Ouvrez le manifeste téléchargé dans un éditeur et remplacez la propriété vide keyCredentials par le JSON suivant :

       "keyCredentials": [
     {
         "customKeyIdentifier" : "$base64Thumbprint_from_above",
         "keyId": "$keyid_from_above",
         "type": "AsymmetricX509Cert",
         "usage": "Verify",
         "value": "$base64Value_from_above"
     }
 ],

    Remarque

    La propriété KeyCredentials est une collection qui permet de charger plusieurs certificats X.509 pour des scénarios de substitution ou de supprimer des certificats pour des scénarios de compromission.

  9. Enregistrez vos modifications et chargez le manifeste mis à jour en cliquant sur Gérer le manifeste dans la barre de commandes, puis sélectionnez Télécharger le manifeste, naviguez jusqu’à votre fichier manifeste mis à jour et sélectionnez-le.

Spécifier les autorisations requises par votre application pour accéder aux API de gestion d’Office 365

Enfin, vous devrez spécifier exactement les autorisations requises par votre application pour les API de gestion d’Office 365. Pour ce faire, vous ajoutez l’accès aux API de gestion d’Office 365 à votre application, puis vous spécifiez les autorisations dont vous avez besoin.

  1. Dans le portail Azure, accédez à Inscriptions d'applications> Toutes les applications, sélectionnez votre application, puis sélectionnez Autorisations d'API (1) dans le volet gauche. Cliquez sur Ajouter une autorisation (2) pour afficher la page volante Demander une autorisation API (3).

    Ajouter des autorisations d'API

  2. Dans l'onglet API Microsoft, sélectionnez API de gestion Office 365 (4).

    Sélectionnez les API de gestion Office 365 dans l'onglet API Microsoft

  3. Sur la page volante, sélectionnez les types d'autorisations suivants (3) dont votre application a besoin, puis cliquez sur Ajouter des autorisations

    Sélectionnez les types d'autorisations pour votre application

    1. Autorisations déléguées. Permet à votre application cliente d'effectuer des opérations au nom de l'utilisateur connecté, telles que la lecture des e-mails ou la modification du profil de l'utilisateur.

    2. Autorisations d'application. Autorisations qui permettent à l'application cliente de s'authentifier en tant qu'elle-même sans interaction ni consentement de l'utilisateur, comme une application utilisée par les services d'arrière-plan ou les applications démon.

  4. Les API Office Management apparaissent désormais dans la liste des applications pour lesquelles votre application nécessite des autorisations. Sous Autorisations d'application et Autorisations déléguées, si nécessaire, sélectionnez les autorisations requises par votre application. Reportez-vous à la référence de l’API spécifique pour plus d’informations sur chaque autorisation.

    Autorisations API pour votre application

  5. Sélectionnez Accorder le consentement de l'administrateur pour « nom du locataire » pour consentir aux autorisations accordées à votre application.

Maintenant que votre application est configurée avec les autorisations requises pour utiliser les API de gestion d’Office 365, un administrateur client doit octroyer ces autorisations explicitement à votre application pour accéder aux données de son client à l’aide des API. Pour accorder son consentement, l’administrateur du locataire doit se connecter à Microsoft Entra ID à l’aide de l’URL spécialement créée suivante, où il peut examiner les autorisations demandées par votre application. Cette étape n’est pas obligatoire lorsque vous utilisez les API pour accéder aux données de votre propre client.

https://login.windows.net/common/oauth2/authorize?response_type=code&resource=https%3A%2F%2Fmanage.office.com&client_id={your_client_id}&redirect_uri={your_redirect_url }

L’URL de redirection doit correspondre ou être un sous-chemin d’accès sous l’une des URL de réponse configurées pour votre application dans Microsoft Entra ID.

Par exemple :

https://login.windows.net/common/oauth2/authorize?response_type=code&resource=https%3A%2F%2Fmanage.office.com&client_id=2d4d11a2-f814-46a7-890a-274a72a7309e&redirect_uri=http%3A%2F%2Fwww.mycompany.com%2Fmyapp%2F

Vous pouvez tester l’URL de consentement en la collant dans un navigateur et en vous connectant à l’aide des informations d’identification d’un administrateur Office 365 pour un client autre que celui que vous avez utilisé pour inscrire l’application. Vous verrez la demande d’octroi d’autorisation à votre application pour utiliser les API de gestion d’Office.

Page de consentement des autorisations

Après avoir sélectionné Accepter, vous êtes redirigé vers la page spécifiée où se trouve un code dans la chaîne de requête.

Par exemple :

http://www.mycompany.com/myapp/?code=AAABAAAAvPM1KaPlrEqdFSB...

Votre application utilise ce code d’autorisation pour obtenir un jeton d’accès à partir de Microsoft Entra ID, à partir duquel l’ID de locataire peut être extrait. Une fois que vous avez extrait et stocké l’ID client, vous pouvez obtenir d’autres jetons d’accès sans demander à l’administrateur client de se connecter.

Demander des jetons d’accès à Microsoft Entra ID

Il existe deux méthodes pour demander des jetons d’accès à partir de Microsoft Entra ID :

  • Le flux d’octroi de code d’autorisation implique qu’un administrateur client donne son consentement explicite, ce qui renvoie un code d’autorisation à votre application. Votre application échange ensuite le code d’autorisation contre un jeton d’accès. Cette méthode est nécessaire pour obtenir le consentement initial requis par votre application pour accéder aux données client à l’aide de l’API. Ce premier jeton d’accès est nécessaire pour obtenir et stocker l’ID client.

  • Le flux d’octroi d’informations d’identification du client permet à votre application de demander d’autres jetons d’accès lorsque les anciens expirent, sans que l’administrateur client doive se connecter et donner explicitement son consentement. Cette méthode doit être utilisée pour les applications qui s’exécutent en continu en arrière-plan appelant les API une fois que le consentement initial de l’administrateur client a été donné.

Demander un jeton d’accès à l’aide du code d’autorisation

Une fois qu’un administrateur de locataire a donné son consentement, votre application reçoit un code d’autorisation en tant que paramètre de chaîne de requête quand Microsoft Entra ID redirige l’administrateur client vers votre URL désignée.

http://www.mycompany.com/myapp/?code=AAABAAAAvPM1KaPlrEqdFSB...

Votre application effectue un POST REST HTTP pour Microsoft Entra ID afin d’échanger le code d’autorisation contre un jeton d’accès. Étant donné que l’ID client n’est pas encore connu, le POST sera effectué sur le point de terminaison « courant », qui ne dispose pas de l’ID client incorporé dans l’URL :

https://login.windows.net/common/oauth2/token

Le corps du POST contient les éléments suivants :

resource=https%3A%2F%2Fmanage.office.com&client_id=a6099727-6b7b-482c-b509-1df309acc563 &redirect_uri= http%3A%2F%2Fwww.mycompany.com%2Fmyapp%2F &client_secret={your_client_key}&grant_type=authorization_code&code= AAABAAAAvPM1KaPlrEqdFSB...

Exemple de demande

POST https://login.windows.net/common/oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: login.windows.net
Content-Length: 944

resource=https%3A%2F%2Fmanage.office.com&client_id=a6099727-6b7b-482c-b509-1df309acc563 &redirect_uri= http%3A%2F%2Fwww.mycompany.com%2Fmyapp%2F &client_secret={your_client_key}&grant_type=authorization_code&code=AAABAAAAvPM1KaPlrEqdFSB...

Le corps de la réponse inclura plusieurs propriétés, y compris le jeton d’accès.

Exemple de réponse

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 3265

{"expires_in":"3599","token_type":"Bearer","scope":"ActivityFeed.Read ActivityReports.Read ServiceHealth.Read","expires_on":"1438290275","not_before":"1438286375","resource":"https://manage.office.com","access_token":"eyJ0eX...","refresh_token":"AAABAAA...","id_token":"eyJ0eXAi..."}

Le jeton d’accès renvoyé est un jeton JWT qui inclut des informations sur l’administrateur qui a donné son consentement et l’application qui demande l’accès. Voici ci-dessous un exemple de jeton non codé. Votre application doit extraire l’ID client « tid » de ce jeton et le stocker afin de pouvoir l’utiliser pour demander d’autres jetons d’accès à leur expiration, sans interaction supplémentaire de l’administrateur.

Exemple de jeton

{
  "aud": "https://manage.office.com",
  "iss": "https://sts.windows.net/41463f53-8812-40f4-890f-865bf6e35190/",
  "iat": 1427246416,
  "nbf": 1427246416,
  "exp": 1427250316,
  "ver": "1.0",
  "tid": "41463f53-8812-40f4-890f-865bf6e35190",
  "amr": [
    "pwd"
  ],
  "oid": "1cef1fdb-ff52-48c4-8e4e-dfb5ea83d357",
  "upn": "admin@contoso.onmicrosoft.com",
  "puid": "1003BFFD8EC47CA6",
  "sub": "7XpD5OWAXM1OWmKiVKh1FOkKXV4N3OSRol6mz1pxxhU",
  "given_name": "John",
  "family_name": "Doe",
  "name": "Contoso, Inc.",
  "unique_name": "admin@contoso.onmicrosoft.com",
  "appid": "a6099727-6b7b-482c-b509-1df309acc563",
  "appidacr": "1",
  "scp": "ActivityFeed.Read ServiceHealth.Read",
  "acr": "1"
}

Demander un jeton d’accès à l’aide des informations d’identification client

Une fois que l’ID de locataire est connu, votre application peut effectuer des appels de service à service pour Microsoft Entra ID demander des jetons d’accès supplémentaires à mesure qu’ils expirent. Ces jetons incluent des informations sur l’application qui demande l’accès uniquement et non sur l’administrateur qui a donné son consentement à l’origine. Les appels de service à service exigent que votre application utilise un certificat X.509 pour créer une assertion client sous la forme d’un jeton de porteur JWT signé SHA256 et codé en base 64.

Lorsque vous développez votre application dans .NET, vous pouvez utiliser la Bibliothèque d’authentification Microsoft (MSAL) pour créer des assertions client. Les autres plateformes de développement doivent avoir des bibliothèques similaires.

Un jeton JWT non codé se compose d’un en-tête et d’une charge utile ayant les propriétés suivantes.

HEADER:

{
  "alg": "RS256",
  "x5t": "{thumbprint of your X.509 certificate used to sign the token",
}

PAYLOAD:

{
  "aud": "https://login.windows.net/{tenantid}/oauth2/token",
  "iss": "{your app client ID}",
  "sub": "{your app client ID}",
  "jti": "{random GUID}",
  "nbf": "{epoch time, before which the token is not valid}",
  "exp": "{epoch time, after which the token is not valid}"
}

Exemple de jeton JWT

HEADER:

{
  "alg": "RS256",
  "x5t": "YyfshJC3rPQ-kpGo5dUaiY5t3iU",
}

PAYLOAD:

{
  "aud": "https://login.windows.net/41463f53-8812-40f4-890f-865bf6e35190/oauth2/token",
  "iss": "a6099727-6b7b-482c-b509-1df309acc563",
  "sub": "a6099727-6b7b-482c-b509-1df309acc563",
  "jti": "0ce254c4-81b1-4a2e-8436-9a8c3b49dfb9",
  "nbf": 1427248048,
  "exp": 1427248648,
}

L’assertion du client est ensuite transmise à Microsoft Entra ID dans le cadre d’un appel de service à service pour demander un jeton d’accès. Lorsque vous utilisez les informations d’identification client pour demander un jeton d’accès, utilisez un POST HTTP sur un point de terminaison spécifique au client, où l’ID client extrait et stocké précédemment est incorporé dans l’URL.

https://login.windows.net/{tenantid}/oauth2/token

Le corps du POST contient les éléments suivants :

resource=https%3A%2F%2Fmanage.office.com&client_id={your_app_client_id}&grant_type=client_credentials&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion={encoded_signed_JWT_token}

Exemple de demande

POST https://login.windows.net/41463f53-8812-40f4-890f-865bf6e35190/oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: login.windows.net
Content-Length: 994

resource=https%3A%2F%2Fmanage.office.com&client_id= a6099727-6b7b-482c-b509-1df309acc563&grant_type=client_credentials &client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Ill5ZnNoSkMzclBRLWtwR281ZFVhaVk1dDNpVSJ9.eyJhdWQiOiJodHRwczpcL1wvbG9naW4ud2luZG93cy5uZXRcLzQxNDYzZjUzLTg4MTItNDBmNC04OTBmLTg2NWJmNmUzNTE5MFwvb2F1dGgyXC90b2tlbiIsImV4cCI6MTQyNzI0ODY0OCwiaXNzIjoiYTYwOTk3MjctNmI3Yi00ODJjLWI1MDktMWRmMzA5YWNjNTYzIiwianRpIjoiMGNlMjU0YzQtODFiMS00YTJlLTg0MzYtOWE4YzNiNDlkZmI5IiwibmJmIjoxNDI3MjQ4MDQ4LCJzdWIiOiJhNjA5OTcyNy02YjdiLTQ4MmMtYjUwOS0xZGYzMDlhY2M1NjMifQ.vfDrmCjiXgoj2JrTkwyOpr-NOeQTzlXQcGlKGNpLLe0oh4Zvjdcim5C7E0UbI3Z2yb9uKQdx9G7GeqS-gVc9kNV_XSSNP4wEQj3iYNKpf_JD2ikUVIWBkOg41BiTuknRJAYOMjiuBE2a6Wyk-vPCs_JMd7Sr-N3LiNZ-TjluuVzWHfok_HWz_wH8AzdoMF3S0HtrjNd9Ld5eI7MVMt4OTpRfh-Syofi7Ow0HN07nKT5FYeC_ThBpGiIoODnMQQtDA2tM7D3D6OlLQRgLfI8ir73PVXWL7V7Zj2RcOiooIeXx38dvuSwYreJYtdphmrDBZ2ehqtduzUZhaHL1iDvLlw

La réponse sera la même qu’avant, mais le jeton n’aura pas les mêmes propriétés, car il ne contient pas les propriétés de l’administrateur qui a donné son consentement.

Exemple de réponse

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 1276

{"token_type":"Bearer","expires_in":"3599","expires_on":"1431659094","not_before":"1431655194","resource":"https://manage.office.com","access_token":"eyJ0eXAiOiJKV1QiL..."}

Exemple de jeton d’accès

{
  "aud": "https://manage.office.com",
  "iss": "https://sts.windows.net/41463f53-8812-40f4-890f-865bf6e35190/",
  "iat": 1431655194,
  "nbf": 1431655194,
  "exp": 1431659094,
  "ver": "1.0",
  "tid": "41463f53-8812-40f4-890f-865bf6e35190",
  "roles": [
    "ServiceHealth.Read",
    "ActivityFeed.Read"
  ],
  "oid": "67cb0334-e242-4783-8028-0f39132fb5ad",
  "sub": "67cb0334-e242-4783-8028-0f39132fb5ad",
  "idp": "https://sts.windows.net/41463f53-8812-40f4-890f-865bf6e35190/",
  "appid": "a6099727-6b7b-482c-b509-1df309acc563",
  "appidacr": "1"
}

Créer votre application

Maintenant que vous avez inscrit votre application dans Microsoft Entra ID et que vous l’avez configurée avec les autorisations nécessaires, vous êtes prêt à créer votre application. Voici quelques-uns des aspects clés à prendre en compte lors de la conception et de la création de votre application.

  • Expérience relative au consentement. Pour obtenir le consentement de vos clients, vous devez les diriger dans un navigateur vers le site web Microsoft Entra, à l’aide de l’URL spécialement conçue précédemment, et vous devez disposer d’un site web vers lequel Microsoft Entra ID redirigera l’administrateur une fois qu’il aura donné son consentement. Ce site web doit extraire le code d’autorisation de l’URL et l’utiliser pour demander un jeton d’accès à partir duquel il peut obtenir l’ID client.

  • Stocker l’ID client dans votre système. Cela sera nécessaire lors de la demande de jetons d’accès à partir de Microsoft Entra ID et lors de l’appel des API de gestion Office.

  • Gérer les jetons d’accès. Vous aurez besoin d’un composant qui demande et gère les jetons d’accès en fonction des besoins. Si votre application appelle les API régulièrement, elle peut demander des jetons à la demande, ou si elle appelle les API en permanence pour récupérer des données, elle peut demander des jetons à des intervalles réguliers (par exemple, toutes les 45 minutes).

  • Implémentez un écouteur de webhook. Selon les besoins de l’API particulière que vous utilisez.

  • Extraction des données et stockage. Vous devez avoir un composant qui récupère les données pour chaque client à l’aide de l’interrogation continue ou en réponse à des notifications de webhook, en fonction de l’API spécifique que vous utilisez.