Share via

Authentifizieren eines Benutzers mit einem SSO-Token in einem Outlook-Add-In

  • Artikel

Single Sign-On bietet Ihrem Add-In eine nahtlose Möglichkeit, Benutzer zu authentifizieren (und optional Zugriffstoken zum Aufrufen der Microsoft Graph-API abzurufen).

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. Optional können Sie auch Ihren serverseitigen Code verwenden.

  • 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 Übersicht über SSO in Office-Add-Ins finden Sie unter Aktivieren des Single Sign-On für Office-Add-Ins und Autorisieren von Microsoft Graph in Ihrem Office-Add-In.

Aktivieren der modernen Authentifizierung in Ihrem Microsoft 365-Mandanten

Um einmaliges Anmelden mit einem Outlook-Add-In zu verwenden, 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.

Registrieren des Add-Ins

Zur Verwendung von SSO benötigt Ihr Outlook-Add-In eine serverseitige Web-API, die bei Azure Active Directory (AAD) v2.0 registriert ist. Weitere Informationen finden Sie unter Registrieren eines Office-Add-Ins, das SSO mit dem Azure AD v2.0-Endpunkt verwendet.

Wenn Sie ein Add-In entwickeln, müssen Sie die Zustimmung im Voraus erteilen. Weitere Informationen finden Sie unter Erteilen der Administratorzustimmung für das Add-In.

Aktualisieren des Add-In-Manifests

Der nächste Schritt zum Aktivieren von SSO im Add-In besteht darin, dem Manifest einige Informationen aus der Microsoft Identity Platform Registrierung des Add-Ins hinzuzufügen. Das Markup variiert je nach Art des Manifests.

  • XML-Manifest: Fügen Sie am Ende des VersionOverridesV1_1VersionOverrides-Elements ein WebApplicationInfo -Element hinzu. Fügen Sie dann die erforderlichen untergeordneten Elemente hinzu. Ausführliche Informationen zum Markup finden Sie unter Konfigurieren des Add-Ins.

  • Einheitliches Manifest für Microsoft 365 (Vorschau): Fügen Sie dem Stammobjekt { ... } im Manifest eine Eigenschaft "webApplicationInfo" hinzu. Weisen Sie diesem Objekt eine untergeordnete "id"-Eigenschaft zu, die auf die Anwendungs-ID der Web-App des Add-Ins festgelegt ist, wie sie beim Registrieren des Add-Ins im Azure-Portal generiert wurde. (Weitere Informationen finden Sie weiter oben in diesem Artikel im Abschnitt Registrieren Ihres Add-Ins .) Weisen Sie ihr außerdem eine untergeordnete "Resource"-Eigenschaft zu, die auf den gleichen Anwendungs-ID-URI festgelegt ist, den Sie beim Registrieren des Add-Ins festgelegt haben. Dieser URI sollte das Format api://<fully-qualified-domain-name>/<application-id>haben. Es folgt ein Beispiel.

    "webApplicationInfo": {
      "id": "a661fed9-f33d-4e95-b6cf-624a34a2f51d",
      "resource": "api://addin.contoso.com/a661fed9-f33d-4e95-b6cf-624a34a2f51d"
  },

Abrufen des SSO-Tokens

Das Add-In ruft ein SSO-Token mit clientseitigem Skript ab. Weitere Informationen finden Sie unter Hinzufügen des clientseitigen Codes.

Verwenden des SSO-Tokens im Back-End

In den meisten Szenarien würde es wenig Sinn machen, das Zugriffstoken abzurufen, wenn das Add-In dieses nicht an eine Serverseite übergibt und es dort verwendet. Informationen dazu, was die Serverseite ausführen kann und sollte, finden Sie unter Hinzufügen des serverseitigen Codes.

Wichtig

Wenn Sie das SSO-Token als Identität in einem Outlook-Add-In verwenden, sollten Sie auch das Exchange-Identitätstoken als eine andere Identität verwenden. Benutzer Ihres Add-Ins verwenden möglicherweise mehrere Clients, von denen einige möglicherweise keine SSO-Token unterstützen. Wenn Sie als Alternative das Exchange-Identitätstoken verwenden, müssen diese Benutzer nicht mehrmals zur Eingabe ihrer Anmeldeinformationen aufgefordert werden. Weitere Informationen finden Sie unter Szenario: Implementieren von Single Sign-On bei Ihrem Dienst in einem Outlook-Add-In.

SSO für ereignisbasierte Aktivierung oder integrierte Spamberichterstattung

Wenn Ihr Add-In die ereignisbasierte Aktivierung oder integrierte Spamberichterstattung (Vorschau) verwendet, sind zusätzliche Schritte erforderlich. Weitere Informationen finden Sie unter Verwenden des einmaligen Anmeldens (Single Sign-On, SSO) oder der ressourcenübergreifenden Ressourcenfreigabe (Cross-Origin Sharing, CORS) in Ihrem ereignisbasierten Oder Spam-Reporting-Outlook-Add-In.

Siehe auch