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. Dies erfordert, dass sich das Add-In im Anwendungsregistrierungsportal registriert und alle erforderlichen Microsoft Graph-Bereiche im Add-In-Manifest angibt, wenn das XML-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 (Vorschau)

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.

Wichtig

Die Authentifizierung geschachtelter Apps befindet sich derzeit in der Vorschauphase. Um dieses Feature auszuprobieren, treten Sie dem Microsoft 365 Insider-Programm (https://insider.microsoft365.com/join) bei, und wählen Sie den Betakanal aus. Verwenden Sie NAA nicht in Produktions-Add-Ins. Wir laden Sie ein, NAA in Test- oder Entwicklungsumgebungen auszuprobieren und Feedback zu Ihrer Erfahrung über GitHub zu begrüßen ( siehe Feedbackabschnitt am Ende dieser Seite).

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-Benutzeridentitätstoken und Rückruftoken werden im Oktober 2024 für alle Exchange Online Mandanten im Rahmen der Microsoft Secure Future Initiative deaktiviert, die Organisationen die Tools bietet, die für die Reaktion auf die aktuelle Bedrohungslandschaft erforderlich sind. Exchange-Benutzeridentitätstoken funktionieren weiterhin für lokale Exchange-Instanzen. Die Authentifizierung geschachtelter Apps ist der empfohlene Ansatz für token in Zukunft. Weitere Informationen finden Sie in unserem Blogbeitrag zur Authentifizierung geschachtelter Apps und älteren Exchange-Token.

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-Benutzeridentitätstoken und Rückruftoken werden im Oktober 2024 für alle Exchange Online Mandanten im Rahmen der Microsoft Secure Future Initiative deaktiviert, die Organisationen die Tools bietet, die für die Reaktion auf die aktuelle Bedrohungslandschaft erforderlich sind. Exchange-Benutzeridentitätstoken funktionieren weiterhin für lokale Exchange-Instanzen. Die Authentifizierung geschachtelter Apps ist der empfohlene Ansatz für token in Zukunft. Weitere Informationen finden Sie in unserem Blogbeitrag zur Authentifizierung geschachtelter Apps und älteren Exchange-Token.

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.