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
Office Add-ins