Freigeben über


Authentifizierungsoptionen in Outlook-Add-Ins

Ihr Outlook-Add-In kann auf Informationen von beliebigen Stellen im Internet zugreifen, sei es vom Server, der das Add-In hostet, vom internen Netzwerk aus oder von einer anderen Stelle in der Cloud aus. Wenn diese Informationen geschützt sind, muss das Add-In Ihren Benutzer authentifizieren. Outlook-Add-Ins bieten je nach Ihrem speziellen Szenario eine Reihe unterschiedlicher Methoden zum Authentifizieren.

Zugriffstoken für einmaliges Anmelden mithilfe des OBO-Flusses

Zugriffstoken für einmaliges Anmelden (Single Sign-On, SSO) bieten eine nahtlose Möglichkeit für Ihr Outlook-Add-In, sich zu authentifizieren und Zugriffstoken zum Aufrufen der Microsoft-Graph-API abzurufen. Durch diese Funktion werden Reibungspunkte reduziert, da der Benutzer keine Anmeldeinformationen eingeben muss. Sie können den On-Behalf-of-Flow mit einem Server der mittleren Ebene oder der geschachtelten App-Authentifizierung (im nächsten Abschnitt beschrieben) verwenden.

Hinweis

SSO mit dem OBO-Fluss wird derzeit für Word, Excel, Outlook und PowerPoint unterstützt. Weitere Informationen zur Unterstützung finden Sie unter IdentityAPI-Anforderungssätze. Wenn Sie mit einem Outlook-Add-In arbeiten, müssen Sie die moderne Authentifizierung für den Microsoft 365-Mandanten aktivieren. Informationen dazu finden Sie unter Aktivieren oder Deaktivieren der modernen Authentifizierung für Outlook in Exchange Online.

Erwägen Sie die Verwendung von SSO-Zugriffstoken, wenn für Ihr Add-In Folgendes gilt:

  • Es wird hauptsächlich von Microsoft 365-Benutzern verwendet
  • Es benötigt Zugriff auf:
    • Microsoft-Dienste, die im Rahmen von Microsoft Graph bereitgestellt werden
    • Ein Nicht-Microsoft-Dienst, den Sie steuern

Die SSO-Authentifizierungsmethode verwendet den von Azure Active Directory bereitgestellten OAuth2-Im-Auftrag-von-Ablauf. Hierfür muss sich das Add-In im Anwendungsregistrierungsportal registrieren und alle erforderlichen Microsoft Graph-Bereiche im Add-In-Manifest angeben, wenn das reine Add-In-Manifest verwendet wird. Wenn das Add-In das einheitliche Manifest für Microsoft 365 verwendet, gibt es eine Manifestkonfiguration, aber Microsoft Graph-Bereiche werden nicht angegeben. Stattdessen werden die erforderlichen Bereiche zur Laufzeit in einem Aufruf zum Abrufen eines Tokens an Microsoft Graph angegeben.

Mit dieser Methode kann Ihr Add-In ein Zugriffstoken abrufen, das auf Ihre Server-Back-End-API ausgelegt ist. Das Add-In verwendet dieses als Bearertoken in der Authorization-Kopfzeile, um einen Aufruf wieder bei Ihrer API zu authentifizieren. An diesem Punkt kann Ihr Server Folgendes:

  • Den Im-Auftrag-von-Ablauf abschließen, um ein Zugriffstoken zu erhalten, das auf die Microsoft Graph-API ausgelegt ist
  • Die Identitätsinformationen im Token verwenden, um die Identität des Benutzers zu ermitteln und bei Ihren eigenen Back-End-Diensten zu authentifizieren

Eine detailliertere Übersicht finden Sie unter Vollständige Übersicht über die SSO-Authentifizierungsmethode.

Informationen zur Verwendung des SSO-Tokens in einem Outlook-Add-In finden Sie unter Authentifizieren eines Benutzers mit einem Single Sign-On-Token in einem Outlook-Add-In.

Ein Beispiel-Add-In, das das SSO-Token verwendet, finden Sie unter Outlook-Add-In SSO.

Zugriffstoken für einmaliges Anmelden mit geschachtelter App-Authentifizierung

Die Authentifizierung geschachtelter Apps (Nested App Authentication, NAA) ermöglicht single Sign-On (SSO) für Office-Add-Ins, die im Kontext nativer Office-Anwendungen ausgeführt werden. Im Vergleich zum on-behalf-of-Flow, der mit Office.js und getAccessToken()verwendet wird, bietet NAA mehr Flexibilität in der App-Architektur und ermöglicht die Erstellung umfangreicher, clientgesteuerter Anwendungen. NAA vereinfacht die Behandlung von SSO für Ihren Add-In-Code. Mit NAA können Sie Microsoft Graph-Aufrufe aus Ihrem Add-In-Clientcode als SPA ausführen, ohne dass ein Server der mittleren Ebene erforderlich ist. Es ist nicht erforderlich, Office.js-APIs zu verwenden, da NAA von der MSAL.js-Bibliothek bereitgestellt wird.

Informationen zum Aktivieren von NAA für Ihr Outlook-Add-In finden Sie unter Aktivieren des einmaligen Anmeldens in einem Office-Add-In mithilfe der Authentifizierung geschachtelter Apps (Vorschau). NAA funktioniert in allen Office-Add-Ins gleich.

Exchange-Benutzeridentitätstoken

Wichtig

Legacy-Exchange-Token sind veraltet. Ab Februar 2025 werden wir ältere Exchange-Benutzeridentitäts- und Rückruftoken für Exchange Online Mandanten deaktivieren. Die Zeitleiste und Details finden Sie auf unserer Faq-Seite. Dies ist Teil der Secure Future Initiative von Microsoft, die Organisationen die Tools zur Verfügung stellt, die sie benötigen, um auf die aktuelle Bedrohungslandschaft zu reagieren. Exchange-Benutzeridentitätstoken funktionieren weiterhin für lokale Exchange-Instanzen. Die Authentifizierung geschachtelter Apps ist der empfohlene Ansatz für token in Zukunft.

Mithilfe von Exchange-Benutzeridentitätstoken kann Ihr Add-In die Identität des Benutzers ermitteln. Indem Sie die Identität des Benutzers überprüfen, können Sie dann eine einmalige Authentifizierung in Ihr Back-End-System durchführen und dann das Benutzeridentitätstoken als Autorisierung für weitere Anforderungen akzeptieren. Verwenden des Exchange-Benutzeridentitätstoken:

  • Wenn das Add-In in erster Linie von lokalen Exchange-Benutzern verwendet wird.
  • Wenn das Add-In Zugriff auf einen Nicht-Microsoft-Dienst benötigt, den Sie steuern.
  • Als alternative Authentifizierung, wenn das Add-In in einer Office-Version ausgeführt wird, die SSO nicht unterstützt.

Das Add-In kann getUserIdentityTokenAsync aufrufen, um Exchange-Benutzeridentitätstoken abzurufen. Weitere Informationen zur Verwendung dieses Tokens finden Sie unter Authentifizieren eines Benutzers mit einem Identitätstoken für Exchange.

Zugriffstoken, die über OAuth2-Flüsse abgerufen wurden

Add-Ins können auch auf Dienste von Microsoft und anderen zugreifen, die OAuth2 für die Autorisierung unterstützen. Erwägen Sie die Verwendung von OAuth2-Token, wenn für Ihr Add-In Folgendes gilt:

  • Benötigt Zugriff auf einen Dienst außerhalb Ihrer Kontrolle.

Mit dieser Methode fordert Ihr Add-In den Benutzer auf, sich beim Dienst anzumelden, indem er entweder die Methode displayDialogAsync verwendet, um den OAuth2-Fluss zu initialisieren.

Rückruftoken

Wichtig

Legacy-Exchange-Token sind veraltet. Ab Februar 2025 werden wir ältere Exchange-Benutzeridentitäts- und Rückruftoken für Exchange Online Mandanten deaktivieren. Die Zeitleiste und Details finden Sie auf unserer Faq-Seite. Dies ist Teil der Secure Future Initiative von Microsoft, die Organisationen die Tools zur Verfügung stellt, die sie benötigen, um auf die aktuelle Bedrohungslandschaft zu reagieren. Exchange-Benutzeridentitätstoken funktionieren weiterhin für lokale Exchange-Instanzen. Die Authentifizierung geschachtelter Apps ist der empfohlene Ansatz für token in Zukunft.

Rückruftoken ermöglichen den Zugriff auf das Postfach des Benutzers von Ihrem Server-Back-End, entweder mithilfe der Exchange-Webdienste (EWS) oder der Outlook REST-API. Erwägen Sie die Verwendung von Rückruftoken, wenn für Ihr Add-In Folgendes gilt:

  • Benötigt Zugriff auf das Postfach des Benutzers von Ihrem Server-Back-End aus.

Add-Ins rufen Rückruftoken mithilfe einer der getCallbackTokenAsync-Methoden ab. Die Zugriffsebene wird durch die im Add-in-Manifest angegebenen Berechtigungen gesteuert.

Siehe auch