Autorisierung bei Nicht-Microsoft-Identitätsanbietern

Neben den Microsoft Identity Platform gibt es viele beliebte Identitätsdienste, die Sie in Ihrem Add-In verwenden können. Sie gewähren Benutzern und Anwendungen wie Ihrem Office-Add-In Zugriff auf die Konten der Benutzer in anderen Anwendungen.

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 den am häufigsten verwendeten Szenarien sendet das Add-In, wenn der Benutzer in dem Office-Add-In eine Aktion ausführt, für die der Onlinedienst erforderlich ist, dem Dienst eine Anforderung für einen bestimmten Satz von Berechtigungen für das Benutzerkonto. Der Dienst fordert dann den Benutzer auf, dem Add-In die jeweiligen Berechtigungen zu gewähren. Nachdem die Berechtigungen erteilt wurden, sendet der Dienst dem Add-In ein kleines codiertes Zugriffstoken. Das Add-In kann den Dienst verwenden, indem das Token in alle Anforderungen an die Dienst-APIs eingeschlossen wird. Aber das Add-In kann nur innerhalb der Berechtigungen fungieren, die der Benutzer erteilt hat. Das Token läuft auch nach einer bestimmten Zeit ab.

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 Autorisierungscodefluss erhalten Sie einen geheimen Clientschlüssel, der verborgen gehalten werden muss. Eine Anwendung ohne serverseitiges Back-End, z. B. eine SPA, hat keine Möglichkeit, den geheimen Schlüssel zu schützen, es wird daher empfohlen, dass Sie in SPAs den impliziten Fluss verwenden.

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 Flows in Office-Add-Ins

Die beste Möglichkeit herauszufinden, ob der Onlinedienst den impliziten Fluss unterstützt, besteht darin, in der Dokumentation der Dienste nachzusehen.

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. Weitere Informationen über einige dieser Bibliotheken 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".

OAuth 2.0 (allgemein): Eine Seite mit Links zu Bibliotheken für mehr als ein Dutzend Sprachen wird von der IETF-OAuth-Arbeitsgruppe an der folgenden Stelle verwaltet: OAuth-Code. Beachten Sie, dass einige dieser Bibliotheken der Implementierung eines OAuth-kompatiblen Diensts dienen. Die Bibliotheken, die für Sie als Add-In-Entwickler von Interesse sind, heißen auf dieser Seite Clientbibliotheken, weil 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 Zwischendienst kann entweder Zugriffstoken für beliebte Onlinedienste bereitstellen oder den Prozess der Aktivierung der Anmeldung bei sozialen Netzwerken für Ihr Add-In oder beides vereinfachen. Mit sehr wenig Code kann Ihr Add-In entweder clientseitiges Skript oder serverseitigen Code verwenden, um eine Verbindung mit dem Middleman-Dienst herzustellen, und es sendet Ihrem Add-In alle erforderlichen Token für den Onlinedienst. Der gesamte Autorisierungsimplementierungscode befindet sich im Middleman-Dienst.

Wir empfehlen, dass die Benutzeroberfläche für die Authentifizierung/Autorisierung in Ihrem Add-In unsere Dialog-APIs verwenden, um eine Anmeldeseite zu öffnen. Weitere Informationen finden Sie unter Authentifizieren mit der Office-Dialogfeld-API . Wenn Sie ein Office-Dialogfeld auf diese Weise öffnen, weist der Dialog eine komplett neue und separate Instanz des Browser- und JavaScript-Moduls im Vergleich zu der Instanz auf der übergeordneten Seite auf (d. h. der Aufgabenbereich oder FunctionFile des Add-Ins). Ein Token und andere Informationen, die in eine Zeichenfolge konvertiert werden können, werden mithilfe einer API mit dem Namen messageParent zurück an das übergeordnete Element übergeben. Die übergeordnete Seite kann dann das Token verwenden, um autorisierte Aufrufe für die Ressource zu tätigen. Aufgrund dieser Architektur müssen Sie bei der Verwendung der APIs, die von einem Zwischendienst bereitgestellt werden, vorsichtig sein. Der Diensts stellt häufig einen API-Satz bereit, in dem Ihr Code eine Art Kontextobjekt erstellt, das ein Token abruft und dieses Token dann in nachfolgenden Aufrufen der Ressource verwendet. Der Dienst verfügt häufig über eine einzelne API-Methode, die den ersten Aufruf tätigt und das Kontextobjekt erstellt. Ein solches Objekt kann nicht vollständig in Zeichenfolgen dargestellt werden, es kann daher nicht vom Office-Dialogfeld an die übergeordnete Seite übergeben werden. Der Zwischendienst stellt in der Regel einen zweiten API-Satz auf einer niedrigeren Abstraktionsebene bereit, z. B. eine REST-API. Dieser zweite Satz verfügt über eine API, die ein Token von dem Dienst abruft, und über andere APIs, die das Token an den Dienst übergeben, wenn es verwendet wird, um autorisierten Zugriff auf die Ressource zu erhalten. Sie müssen mit einer API auf dieser niedrigeren Abstraktionsebene arbeiten, damit Sie das Token im Office-Dialogfeld abrufen und dann messageParent verwenden können, um es an die übergeordnete Seite zu übergeben.

Was ist CORS?

CORS steht für Cross Origin Resource Sharing. Informationen darüber, wie Sie CORS innerhalb von Add-Ins verwenden, finden Sie unter Behandeln von Richtlinieneinschränkungen aufgrund desselben Ursprungs in Office-Add-Ins.

Siehe auch

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