web-dev-qa-db-fra.com

Comment obtenir le jeton d'accès OAuth2 pour l'API gérée EWS dans une application de service / démon

Scénario

J'ai un environnement Exchange Online et une application service/daemin (aucun utilisateur interactif) sur la machine virtuelle Azure. Le service utilise l'API gérée EWS pour travailler avec les e-mails dans la boîte aux lettres de tout utilisateur locataire. Désormais, le client EWS utilise l'authentification de base qui, selon Microsoft, ne sera plus prise en charge dans EWS pour accéder à Exchange Online.

Question/problème

Donc, je dois trouver un moyen d'obtenir un jeton d'accès valide pour l'application de service/démon à utiliser avec l'API gérée EWS.

Mes découvertes

L'exemple suivant article montre un exemple d'utilisation de OAuth 2.0 avec l'API gérée par EWS. Cet exemple fonctionne, mais il utilise une méthode interactive pour obtenir le consentement (un formulaire de connexion apparaît permettant l'utilisateur s'authentifie et accorde l'autorisation demandée à l'application) qui ne convient pas au scénario d'application de service/démon, car il n'y a pas d'utilisateur interactif.

Pour l'application de service/démon, je dois utiliser client credential flux d'authentification.

Candidature enregistrée

En utilisant le compte administrateur sur https://aad.portal.Azure.com portail, j'ai enregistré l'application avec Azure Active Directory. Secret client ajouté pour l'application enregistrée.

Ci-dessus article utilise https://Outlook.office.com/EWS.AccessAsUser.All en tant que scope. Mais je n'ai pas trouvé d'autorisation avec une telle URL sur le portail. Je n'ai trouvé que les autorisations suivantes sous Office 365 Exchange Online> Application permissions> Mail:

  1. https://Outlook.office365.com/Mail.Read Permet à l'application de lire le courrier dans toutes les boîtes aux lettres sans utilisateur connecté
  2. https://Outlook.office365.com/Mail.ReadWrite Permet à l'application de créer, lire, mettre à jour et supprimer du courrier dans toutes les boîtes aux lettres sans utilisateur connecté.

J'ai ajouté les deux et accordé le consentement de l'administrateur à tous les utilisateurs.

Obtenir un jeton d'accès

À des fins de test et de simplicité, je n'ai utilisé aucune bibliothèque d'authentification (ADAL, MSAL, etc.). J'ai utilisé Postman pour obtenir un jeton d'accès, puis j'ai défini la variable token dans le débogage (voir l'extrait de code plus loin dans l'article).

J'ai essayé différents points de terminaison pour obtenir un jeton d'accès.

  1. Point de terminaison du jeton OAuth 2.0 (v2) 
    POST: https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token
        grant_type=client_credentials
        client_id=*** 
        client_secret=***
        scope=https://Outlook.office.com/EWS.AccessAsUser.All

L'envoi de cette demande produit la réponse d'erreur suivante:

AADSTS70011: La demande fournie doit inclure un paramètre d'entrée "scope". La valeur fournie pour le paramètre d'entrée "scope" n'est pas valide. La portée https://Outlook.office.com/EWS.AccessAsUser.All n'est pas valide.

J'ai essayé de remplacer scope par https://Outlook.office.com/.default. Le jeton d'accès a été retourné, mais il semble non valide pour EWS. Le client EWS génère une erreur 401 avec la valeur suivante de x-ms-diagnostics en-tête de réponse:

2000008; reason = "Le jeton ne contient aucune autorisation ou les autorisations ne peuvent pas être comprises."; Error_category = "invalid_grant"

  1. Point de terminaison du jeton OAuth 2.0 (v1) 
    POST: https://login.microsoftonline.com/<TENANT_ID>/oauth2/token
        grant_type=client_credentials
        client_id=*** 
        client_secret=***
        resource=https://Outlook.office.com

Le jeton d'accès a été retourné, mais semble également non valide pour EWS. Le client EWS renvoie une erreur 401 avec la même valeur de x-ms-diagnostics en-tête de réponse comme décrit précédemment dans # 1.

Utiliser un jeton d'accès acquis avec l'API gérée EWS

Voici un exemple de code que j'ai utilisé pour tester le client EWS avec un jeton d'accès acquis dans Postman:

var token = "...";
var client = new ExchangeService
{
    Url = new Uri("https://Outlook.office365.com/EWS/Exchange.asmx"),
    Credentials = new OAuthCredentials(token),
    ImpersonatedUserId = new ImpersonatedUserId(ConnectingIdType.SmtpAddress,
                 "[email protected]"),

};
var folder = Folder.Bind(client, WellKnownFolderName.SentItems);
c#oauth-2.0office365exchangewebservices
3
Oleksii

Je rencontre le même problème en suivant les documents officiels de Microsoft pour flux d'informations d'identification du client OAuth 2.

Selon la plate-forme d'identité Microsoft et le flux d'informations d'identification du client OAuth 2. , la portée "doit être l'identificateur de ressource (URI de l'ID d'application) de la ressource que vous souhaitez, apposée avec le suffixe .default "(voir doc de portée par défaut ).

La question est donc de savoir comment convertir https://Outlook.office.com/EWS.AccessAsUser.All dans l'identificateur de ressource.

Expérimentalement, je parviens à le faire fonctionner en utilisant scope=https://Outlook.office365.com/.default. J'ai accordé full_access_as_app (Office 365 Exchange Online/Autorisations d'application) et obtenu le consentement de l'administrateur pour cela.

0
Alexey

J'ai rencontré ce problème lors de l'implémentation de OAuth pour EWS. Mon application est pas à l'aide de EWS Managed API . Voici tout ce que j'ai fait pour le faire fonctionner.

  1. Ajout d'une autorisation Office 365 Exchange Online > full_access_as_app à l'application.
  2. Jeton d'accès acquis pour la portée https://Outlook.office365.com/.default.
POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token

form-data = {
  client_id,
  client_secret,
  grant_type: 'client_credentials',
  scope: 'https://Outlook.office365.com/.default',
};
  1. Ajout d'un jeton d'accès en tant qu'en-tête Authorization et ExchangeImpersonation SOAP en-tête à la demande).
<SOAP-ENV:Header>
  <t:ExchangeImpersonation>
    <t:ConnectingSID>
      <t:PrimarySmtpAddress>[email protected]</t:PrimarySmtpAddress>
    </t:ConnectingSID>
  </t:ExchangeImpersonation>
</SOAP-ENV:Header>
0
kushwahav