Autorisierung bei Nicht-Microsoft-Identitätsanbietern

Viele Identitätsanbieter können zusätzlich zur Microsoft Identity Platform mit Ihrem Add-In arbeiten. Diese Anbieter ermöglichen es Benutzern, einem Office-Add-In Zugriff auf ihre Konten in anderen Diensten zu 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, für die ein anderer Dienst erforderlich ist. 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 schließt das Token in Anforderungen an die APIs des Diensts ein. Das Token gewährt nur die Berechtigungen, die der Benutzer genehmigt hat, und läuft nach einem angegebenen Zeitraum ab.

OAuth 2.0-Flow auswählen

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 für SPAs der implizite Ablauf 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.

Hinweis

Sie haben auch die Möglichkeit, einem Zwischendienst die gesamte Autorisierung zu überlassen und das Zugriffstoken an das Add-In zu übergeben. Details zu diesem Szenario finden Sie im Abschnitt Zwischendienste weiter unten in diesem Artikel.

Verwenden des impliziten Flusses in Office-Add-Ins

Lesen Sie in der Dokumentation des Identitätsanbieters, um sicherzustellen, dass er den impliziten Fluss unterstützt.

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

Verwenden des Autorisierungscodeflusses 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".
  • General OAuth 2.0: Die IETF OAuth Working Group verwaltet OAuth Code, eine Seite mit Bibliothekslinks für mehr als ein Dutzend Sprachen. Einige dieser Bibliotheken dienen zur Implementierung eines OAuth-kompatiblen Diensts. Suchen Sie bei einem Office-Add-In nach Clientbibliotheken , da Ihr Webserver ein Client des OAuth-kompatiblen Diensts ist.

Zwischendienste

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

Es wird empfohlen, dass die Benutzeroberfläche für Authentifizierung und Autorisierung in Ihrem Add-In die Office-Dialogfeld-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 es in einer Browser- und JavaScript-Engine-Instanz ausgeführt, die von der übergeordneten Seite getrennt ist, z. B. im Aufgabenbereich oder in der Funktionsdatei des Add-Ins. Ein Token und alle anderen Informationen, die in eine Zeichenfolge umgewandelt werden können, werden mithilfe von messageParentan das übergeordnete Element zurückgegeben. Die übergeordnete Seite kann dann das Token verwenden, um autorisierte Aufrufe für die Ressource zu tätigen.

Seien Sie aufgrund dieser Architektur vorsichtig, wenn Sie APIs von einem Mittelsdienst verwenden. Einige Dienste stellen einen API-Satz bereit, in dem der Code ein Kontextobjekt erstellt, das ein Token abruft und 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 in Zeichenfolgen umgewandelt werden, daher kann es nicht vom Office-Dialogfeld an die übergeordnete Seite übergeben werden.

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 umfasst in der Regel eine API, die ein Token vom Dienst abruft, sowie andere APIs, die das Token beim Anfordern des Zugriffs auf die Ressource an den Dienst zurückgeben. Verwenden Sie diesen API-Satz auf niedrigerer Ebene, damit das Office-Dialogfeld das Token abrufen und dann mithilfe von an die übergeordnete Seite messageParentü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 der Einschränkungen der Richtlinie gleichen Ursprungs in Office-Add-Ins.

Siehe auch

  • Last updated on