Autorisierung bei Nicht-Microsoft-Identitätsanbietern

Neben den Microsoft Identity Platform können viele Identitätsanbieter mit Ihrem Add-In verwendet werden. Mit diesen Anbietern können Benutzer einem Office-Add-In Zugriff auf ihre Konten in anderen Diensten gewähren.

Das Standardframework in der Branche zum Aktivieren des Webanwendungszugriffs auf einen Onlinedienst ist OAuth 2.0. In den meisten Fällen müssen Sie nicht wissen, wie das Framework im Detail arbeitet, um es in Ihrem Add-In verwenden zu können. Es gibt viele Bibliotheken, in denen die Details für Sie vereinfacht werden.

Eine grundlegende Vorstellung von OAuth besteht darin, dass eine Anwendung ein Sicherheitsprinzipal für sich selbst ist, genau wie ein Benutzer oder eine Gruppe, mit eigener Identität und eigenem Berechtigungssatz. In einem typischen Flow führt ein Benutzer eine Aktion im Add-In aus, die einen anderen Dienst erfordert. Das Add-In fordert einen bestimmten Satz von Berechtigungen für das Konto dieses Benutzers an. Der Dienst fordert den Benutzer dann auf, diese Berechtigungen zu erteilen.

Nachdem die Berechtigung erteilt wurde, sendet der Dienst dem Add-In ein codiertes Zugriffstoken. Das Add-In enthält das Token in Anforderungen an die APIs des Diensts. Das Token gewährt nur die Berechtigungen, die der Benutzer genehmigt hat, und läuft nach einer angegebenen Zeit ab.

Auswählen eines OAuth 2.0-Flows

Unterschiedliche OAuth-Muster, die als Flüsse oder Erteilungstypen bezeichnet werden, sind für unterschiedliche Szenarien vorgesehen. Die folgenden beiden Muster werden am häufigsten implementiert.

• Impliziter Fluss: Die Kommunikation zwischen dem Add-In und dem Onlinedienst wird mit dem clientseitigen JavaScript implementiert. Dieser Fluss wird häufig in Anwendungen mit einer Seite (SPAs) verwendet.
• Autorisierungscodefluss: Die Kommunikation erfolgt von Server zu Server zwischen der Webanwendung Ihres Add-Ins und dem Onlinedienst. Sie wird also mit serverseitigem Code implementiert.

Der Zweck eines OAuth-Flusses besteht darin, die Identität und Autorisierung der Anwendung zu schützen. Im Autorisierungscodeflow gibt der Identitätsanbieter einen geheimen Clientschlüssel aus, der vertraulich bleiben muss. Eine Anwendung ohne serverseitiges Back-End, z. B. eine SPA, kann dieses Geheimnis nicht sicher speichern. Daher wird der implizite Fluss für SPAs empfohlen.

Sie sollten die Vor- und Nachteile des impliziten Flusses und des Autorisierungscodeflusses kennen. Weitere Informationen zu diesen beiden Flüssen finden Sie unter Autorisierungscode und Implizit.

Verwenden des impliziten Flows in Office-Add-Ins

Überprüfen Sie die Dokumentation des Identitätsanbieters, um zu bestätigen, dass er den impliziten Flow unterstützt.

Informationen zu Bibliotheken, die den impliziten Fluss unterstützen, finden Sie im Abschnitt Bibliotheken weiter unten in diesem Artikel.

Verwenden des Autorisierungscodeflows in Office-Add-Ins

Es stehen viele Bibliotheken zur Implementierung des Autorisierungscodeflusses in verschiedenen Sprachen und Frameworks zur Verfügung. Einige Beispiele finden Sie im Abschnitt Bibliotheken weiter unten in diesem Artikel.

Bibliotheken

Bibliotheken sind für viele Sprachen und Plattformen verfügbar, sowohl für den impliziten Fluss als auch für den Autorisierungscodefluss. Einige Bibliotheken dienen einem allgemeinen Zweck, andere richten sich an spezifische Onlinedienste.

• Facebook: Durchsuchen Sie Facebook für Entwickler nach "Bibliothek" oder "sdk".
• Allgemein OAuth 2.0: Die IETF OAuth-Arbeitsgruppe verwaltet OAuth-Code, eine Seite mit Bibliothekslinks für mehr als ein Dutzend Sprachen. Einige dieser Bibliotheken dienen zum Implementieren eines OAuth-kompatiblen Diensts. Suchen Sie für ein Office-Add-In nach Clientbibliotheken , da Ihr Webserver ein Client des OAuth-kompatiblen Diensts ist.

Zwischendienste

Ihr Add-In kann einen Zwischendienst wie OAuth.io oder Auth0 verwenden, um die Autorisierung durchzuführen. Ein Vermittlerdienst kann Zugriffstoken für beliebte Onlinedienste bereitstellen, die Anmeldung in sozialen Netzwerken für Ihr Add-In vereinfachen oder beides. Ihr Add-In kann eine Verbindung mit dem Vermittlerdienst entweder mit clientseitigem Skript oder serverseitigem Code herstellen, und der Zwischendienst gibt alle erforderlichen Token für den Onlinedienst zurück.

Es wird empfohlen, dass die Benutzeroberfläche für die Authentifizierung und Autorisierung in Ihrem Add-In die Office-Dialog-API verwendet, um eine Anmeldeseite zu öffnen. Weitere Informationen finden Sie unter Authentifizieren und Autorisieren mit der Office-Dialog-API.

Wenn Sie ein Office-Dialogfeld auf diese Weise öffnen, wird das Dialogfeld in einem separaten Browser und javaScript-engine instance von der übergeordneten Seite ausgeführt, z. B. im Aufgabenbereich oder in der Funktionsdatei des Add-Ins. Ein Token und alle anderen Informationen, die in eine Zeichenfolge konvertiert werden können, werden mithilfe messageParentvon an das übergeordnete Element zurückgegeben. Die übergeordnete Seite kann dann das Token verwenden, um autorisierte Aufrufe für die Ressource zu tätigen.

Gehen Sie aufgrund dieser Architektur vorsichtig vor, wenn Sie APIs von einem Zwischendienst verwenden. Einige Dienste stellen einen API-Satz bereit, in dem der Code ein Kontextobjekt erstellt, das sowohl ein Token abruft als auch dieses Token in späteren Aufrufen der Ressource verwendet. Einige Dienste verwenden sogar eine einzelne API-Methode, die sowohl den ersten Aufruf als auch das Kontextobjekt erstellt. Ein Objekt wie dieses kann nicht vollständig mit Zeichenfolgen versehen werden, sodass es nicht aus dem Office-Dialogfeld an die übergeordnete Seite übergeben werden kann.

Middleman-Dienste stellen in der Regel auch einen zweiten API-Satz auf einer niedrigeren Abstraktionsebene bereit, z. B. eine REST-API. Dieser API-Satz auf niedrigerer Ebene enthält in der Regel eine API, die ein Token vom Dienst abruft, und andere APIs, die das Token beim Anfordern des Zugriffs auf die Ressource zurück an den Dienst übergeben. Verwenden Sie diesen API-Satz auf niedrigerer Ebene, damit das Office-Dialogfeld das Token abrufen und dann mithilfe von messageParentan die übergeordnete Seite übergeben kann.

Was ist CORS?

CORS steht für Cross-Origin Resource Sharing. Informationen zur Verwendung von CORS in Add-Ins finden Sie unter Behandeln von Richtlinienbeschränkungen desselben Ursprungs in Office-Add-Ins.

Siehe auch

• Übersicht über Authentifizierung und Autorisierung in Office-Add-Ins