Freigeben über

Erstellen und Verwenden von Zugriffs-Tokens in vom Anbieter gehosteten SharePoint-Add-Ins mit hoher Vertrauenswürdigkeit

  • Artikel

Wichtig

In diesem Artikel geht es um die Verwendung von Zugriffstoken im Autorisierungssystem mit hoher Vertrauensebene, nicht um das ACS-System. Informationen über die Verwendung von Sicherheitstoken im ACS-System finden Sie unter Handhabung von Sicherheitstoken in vom Anbieter gehosteten Add-Ins für SharePoint mit niedriger Vertrauensebene.

SharePoint-Add-Ins, die das Autorisierungssystem mit hoher Vertrauenswürdigkeit verwenden, um Zugriff auf SharePoint zu erhalten, müssen mit jeder Erstellen-, Lesen-, Aktualisieren- oder Löschenanforderung (CRUD) ein Zugriffstoken (im JSON-Webtoken- Format) an SharePoint übergeben. SharePoint überprüft das Token und verarbeitet die Anforderung.

Dieser Artikel enthält Informationen darüber, wie Ihr Code das Zugriffstoken erstellt und übergibt.

Im Autorisierungssystem mit hoher Vertrauensebene erstellt die Remotekomponente Ihres SharePoint-Add-Ins das Zugriffstoken. Wenn die Remotekomponente verwalteten Code für den serverseitigen Code verwendet, wird die Programmierarbeit für das Erstellen des Tokens größtenteils in den Dateien SharePointContext.cs (oder .vb) und TokenHelper.cs (oder .vb) erledigt, die in den Office Developer Tools für Visual Studio enthalten sind.

Da der Kunde einer SharePoint Add-In mit hoher Vertrauenswürdigkeit über lokales SharePoint verfügt, ist er wahrscheinlich nicht abgeneigt, ASP.NET IIS und Windows Server als Hostingstapel für die Remotekomponente zu verwenden. Sie sollten die Verwendung dieses Stapels in Betracht ziehen, da die beiden generierten Dateien Ihnen eine Menge Programmier- und Testarbeit abnehmen.

Wenn die Remotekomponente eine Nicht-.NET-Sprache verwenden muss und sowohl die Remotekomponente als auch die SharePoint-Farm mit dem Internet verbunden sind, empfehlen wir die Verwendung des Autorisierungssystems mit niedriger Vertrauenswürdigkeit anstatt der hohen Vertrauenswürdigkeit. Im Microsoft Azure Access Control Service (ACS)-System wird das Erstellen aller Token von ACS ausgeführt, sodass Sie sich eine Menge Arbeit sparen.

Der übrige Teil dieses Artikels soll in erster Linie als Anleitung für Entwickler dienen, die SharePoint-Add-Ins mit Nicht-.NET-Remotekomponenten erstellen und das Autorisierungssystem mit hoher Vertrauenswürdigkeit verwenden. Er enthält auch einige wertvolle Informationen für das Debuggen von .NET-basierten-SharePoint-Add-Ins, die das System mit hoher Vertrauenswürdigkeit verwenden.

Handhabung von Zugriffstoken

Hinweis

Denken Sie beim Lesen dieses Artikels vor allem im Zusammenhang mit Aufgaben, die der Code ausführen muss, daran, dass die Microsoft Office Developer Tools für Visual Studio bei der Verwendung von verwaltetem Code zu jedem SharePoint-Add-In-Projekt die zwei generierten Codedateien SharePointContext.cs (oder .vb) und TokenHelper.cs (oder .vb) hinzufügen, die die meisten der Aufgaben für Sie erledigen. Der Weitergabecode des Anwendungstoken besteht in der Regel aus lediglich ein paar Aufrufen der Klassen in diesen Dateien.

Die Details in diesem Thema sollen Entwicklern helfen, die nicht mit verwaltetem Code arbeiten (und bei der Behebung von Problemen mit Token helfen). Links zu OAuth-Bibliotheken für zahlreiche Sprachen und Plattformen finden Sie unter OAuth 2.0 (scrollen Sie zu Client-Bibliotheken). Weitere Informationen finden Sie, indem Sie GitHub nach "OAuth 2" und "JSON Web Token" (ohne Anführungszeichen) durchsuchen.

Ihr Code muss:

  1. Ein Zugriffstoken erstellen. Die Teilaufgaben zum Erstellen dieses Tokens variieren je nachdem, ob die Remote-Webanwendung nur Add-In-Aufrufe an SharePoint, Benutzer-und-Add-In-Aufrufe oder beides durchführt. (Weitere Informationen finden Sie unter Add-In-Autorisierungsrichtlinientypen in SharePoint.)

    • Wenn das Add-In Benutzer-und-Add-In-Aufrufe durchführt, umfasst das Erstellen des Zugriffstokens die folgenden Teilaufgaben:

      1. Erstellen eines Akteurtokens, das das SharePoint-Add-In identifiziert und SharePoint aufträgt, die Benutzerauthentifizierung und Autorisierung für das Add-In zu delegieren und in Base64-Codierung zu codieren. Einzelheiten zu den Ansprüchen und der Struktur des Akteurtokens finden Sie in Tabelle 2. Details zum Codieren und Signieren des Tokens finden Sie unter Codieren und Signieren von Token.
      2. Signieren Sie das Akteurtoken mit Anmeldeinformationen aus einem X.509-Zertifikat, das ein SharePoint-Farmadministrator so konfiguriert hat, dass SharePoint ihm vertraut.
      3. Schließen Sie das Akteuertoken in das Zugriffstoken ein.
      4. Fügen Sie andere erforderliche Ansprüche zum Zugriffstoken hinzu. Einzelheiten zu den Ansprüchen und der Struktur des Tokens finden Sie in Tabelle 1.

    • Wenn das Add-In Nur-Add-In-Aufrufe durchführt, muss Ihr Code nur die ersten zwei dieser Teilaufgaben ausführen. Das Akteurtoken dient als Zugriffstoken.

    • Wenn das Add-In einige Benutzer-und-Add-In-Aufrufe und einige Nur-Add-In-Aufrufe durchführt, muss sie ein einfaches Actor-Token für die Nur-Add-In-Aufrufe und das größere, verschachtelte Zugriffstoken für die Benutzer-und-App-Aufrufe erstellen. Es können nicht dieselben Zugriffstoken für beide Arten von Aufrufen verwendet werden.

  2. Schließen Sie das Zugriffstoken in jede HTTP-Anforderung an SharePoint ein. Das Token wird der Anforderung als Authorization-Header hinzugefügt. Der Wert des Headers ist das Wort "Bearer", gefolgt von einem Leerzeichen, gefolgt von dem Base64-codierten Zugriffstoken.

  3. Optional können Sie das Zugriffstoken zwischenspeichern, damit es in nachfolgenden Anforderungen erneut verwendet werden kann.

Diese Aufgaben müssen mit serverseitigem Code ausgeführt werden. Wenn Sie verwalteten Code verwenden, finden Sie Beispielcode für einige dieser Aufgaben in den Dateien SharePointContext.cs (oder .vb) und TokenHelper.cs (oder .vb), die von den Microsoft Office Developer Tools für Visual Studio generiert werden.

Zwischenspeichern des Zugriffstokens

Nachdem ein Token erstellt wurde, kann es in späteren Aufrufen von SharePoint wiederverwendet werden, bis es abläuft. Je nach der Architektur der Remotekomponente und der Hostingplattform gibt es verschiedene Wege zum Zwischenspeichern des Zugriffstokens auf dem Server:

Wenn der Cachespeicher von mehreren Benutzersitzungen geteilt wird, wie z. B. der Anwendungscache, müssen Sie unbedingt einen separaten Cacheschlüssel für die Sitzung verwenden.

Wenn der Cache von mehreren Anwendungen geteilt wird, muss Ihr Code zudem für diese Variable den Cacheschlüssel relativieren. Es ist auch möglich, dass Ihr Add-In auf mehrere SharePoint-Farmen zugreift. Sie benötigen für jede unterschiedliche Zugriffstoken, sodass der Cacheschlüssel in diesem Szenario für die Farm relativiert werden muss.

Alles in allem benötigen Sie möglicherweise Cacheschlüssel, die auf einer oder mehreren Benutzer-IDs, Anwendungs-IDs und SharePoint-Domänen oder -Bereichen basieren. Ziehen Sie in Betracht, ein Cacheschlüsselsystem ähnlich dem System der SharePoint-Add-Ins zu verwenden, das auf dem Autorisierungssystem mit geringer Vertrauenswürdigkeit beruht. Weitere Informationen finden Sie unter Grundlegendes zum Cacheschlüssel.

Im Wesentlichen würden Sie eine oder mehrere dieser drei IDs zu einem Cacheschlüssel verketten (und das Ergebnis optional in eine kürzere Zeichenfolge hashen).

Umgang mit abgelaufenen Zugriffstoken

Das Zugriffstoken hat einen Ablaufzeitpunkt, den Ihr Code auf einen beliebigen Wert festlegen kann. Wenn Ihr Add-In ein neues Zugriffstoken für jede Anforderung erstellt, muss jedes Token nur lange genug gültig sein, um von SharePoint validiert zu werden, das heißt, nicht mehr als einige Sekunden, solange das LAN des Kunden nicht meistens überlastet ist. Sie könnten den Ablaufzeitpunkt auch auf mehrere Jahre in der Zukunft festlegen, aber selbst im „komplett lokalen" Szenario, für das besonders vertrauenswürdige Add-Ins ausgelegt sind, besteht die Gefahr, dass Zugriffstoken gestohlen werden. Deshalb sollten Sie den Ablaufzeitpunkt nicht auf mehr als einige Stunden festlegen (Wenn Sie mit verwaltetem Code arbeiten, legt der Beispielcode für die Tokenerstellung in der Datei TokenHelper.cs [oder .vb] die Ablauffrist auf 12 Stunden fest.)

Wenn eine Benutzersitzung mit dem SharePoint-Add-In länger dauert als die Lebensdauer des zwischengespeicherten Zugriffstokens, wird durch die erste Anforderung an SharePoint nach Ablauf des Tokens ein 401 Nicht autorisiert-Fehler ausgelöst. Ihr Code muss diese Antwort verarbeiten. Alternativ kann er den Ablaufzeitpunkt des Zugriffstokens testen, bevor es verwendet wird. Ihr Code sollte auf ein abgelaufenes Zugriffstoken antworten, indem er ein neues Zugriffstoken erstellt und die fehlgeschlagene Anforderung wiederholt.

Struktur von Zugriffstoken

Nachfolgend finden Sie ein Beispiel für ein von einem SharePoint-Add-In mit hoher Vertrauenswürdigkeit generiertes Zugriffstoken; dieses Token wurde insbesondere vom Beispielcode der Datei TokenHelper.cs (oder .vb) generiert, die Teil der SharePoint-Add-In-Projektvorlage ist, die von den Office Developer Tools für Visual Studio erstellt wird. Das Token wurde decodiert, und aus Gründen der besseren Lesbarkeit wurden Leerräume hinzugefügt. Die im System mit hoher Vertrauenswürdigkeit verwenden Zugriffstoken sind mit dem MS-SPS2SAUTH: OAuth 2.0-Authentifizierungsprotokoll: SharePoint-Profil kompatibel, das auch Server-zu-Server- oder S2S-Protokoll genannt wird. Diese Informationen werden bereitgestellt, um Entwicklern beim Debuggen von SharePoint-Add-Ins mit hoher Vertrauenswürdigkeit anhand von verwaltetem Code zu helfen und Entwicklern, die andere Sprachen verwenden, Richtlinien zum Erstellen von Tokens zu bieten.

Dieses Zugriffstoken wird generiert, wenn das Add-In einen Aufruf an SharePoint unter Verwendung der Benutzer-und-Add-In-Richtlinie durchführt. Wenn das Add-In die Nur-Add-In-Richtlinie verwendet und einen Nur-Add-In-Aufruf an SharePoint durchführt, wird das Akteurtoken (das ein untergeordnetes Token innerhalb eines Benutzer-und-Add-In-Zugriffstokens ist und später beschrieben wird) zum Zugriffstoken (und es gibt kein übergeordnetes Token).

Hinweis

Beachten Sie, dass sich die von Ihrem Code erstellten besonders vertrauenswürdigen Zugriffstoken von den von Azure ACS erstellten Token unterscheiden, wenn das Autorisierungssystem mit niedriger Vertrauensebene verwendet wird:

  • Der alg-Anspruch im Header ist „Keine", da das Zugriffstoken in einem Benutzer-und-Add-In-Aufruf von einem besonders vertrauenswürdigen Add-In nicht signiert ist.
  • Die Add-In-URL im Wert aud in diesem Beispiel befindet sich auf einem lokalen Server, was für das besonders vertrauenswürdige System normal ist.
  • Es gibt keinen identityprovider-Anspruch, jedoch einen nii (Namensidentitätsherausgeber) mit derselben Art von Werten wie bei den identityprovider-Anspruchzugriffstoken, die im wenig vertrauenswürdigen Autorisierungssystem verwendet werden. (Informationen zu diesem Wert bei einem SAML-basierten Identitätsanbieter finden Sie in Steve Peschkas Blogeinträgen Sicherheit in SharePoint-Add-Ins - Teil 8 und Verwenden von SharePoint-Add-Ins mit SAML- und FBA-Websites in SharePoint 2013.
  • Es gibt keinen actor-Anspruch, aber einen actortoken-Anspruch, der ein Base64-codiertes inneres Token mit einer Gültigkeitsdauer von 12 Stunden enthält.

Die Kopfzeile verfügt über zwei Eigenschaften. Der "Typ" ist der Typ des Tokens. Der Code in der Remote-Webanwendung sollte diesen Wert immer auf "JWT" festlegen. "alg" ist der Algorithmus, der verwendet wird, um das Token zu signieren. Da das äußere Token in einem Benutzer-und-Add-In-Aufruf eines besonders vertrauenswürdigen Add-Ins nicht signiert ist, setzen Sie diesen Wert auf „Keine“. In Tabelle 1 finden Sie Informationen zu den Werten im Textteil des Zugriffstokens mit hoher Vertrauenswürdigkeit.

{"typ":"JWT", "alg":"none"} 
.
{
 "aud":"00000003-0000-0ff1-ce00-000000000000/MarketingServer@52aa6841-b76b-4ed4-a3d7-a259fce1dfa2",
 "iss":"c3ab8885-458f-4864-8804-1608145e2ac4@52aa6841-b76b-4ed4-a3d7-a259fce1dfa2",
 "nbf":"1403212820",
 "exp":"1403256020",
 "nameid":"s-1-5-21-2127521184-1604012920-1887927527-2963467",
 "nii":"urn:office:idp:activedirectory",
 "actortoken":"6sMZhbw … [remainder of long base 64 string omitted] … "
}

Die folgende Tabelle enthält einige Richtlinien für die Eigenschaften, die Ihr Code in die Zugriffstoken integrieren sollte, und die Werte, die für diese Eigenschaften festgelegt werden sollten. Wenn Sie verwalteten Code verwenden, erstellen die Dateien SharePointContext.cs (oder .vb) und TokenHelper.cs (oder .vb) die Token für Sie. Beispiel: Ihr Code richtet einen einzelnen Aufruf an die SharePointContext.CreateUserClientContextForSPHost-Methode. Diese ruft wiederum Methoden in der TokenHelper-Klasse auf, die das Zugriffstoken erstellen, das dann in jedem Aufruf an SharePoint durch das SharePoint- Clientkontextobjekt enthalten ist, das von SharePointContext.CreateUserClientContextForSPHost zurückgegeben wird.

Tabelle 1: Von Apps ausgegebene Zugriffstokenansprüche

Anspruch Beschreibung Entsprechender Wert im Beispiel-Zugriffstoken
aud Abkürzung für "audience", das ist der Prinzipal, für den das Token vorgesehen ist.

Das Format ist Zielgruppenprinzipal-ID/vollqualifizierte SharePoint-Domäne@SharePoint-Bereich.

Der Zielprinzipal für ein SharePoint-Add-In ist immer 00000003-0000-0ff1-ce00-000000000000.

Da besonders vertrauenswürdige SharePoint-Add-Ins normalerweise in einem komplett lokalen Szenario verwendet werden, ist der vollqualifizierte SharePoint-Domänenname oft einfach nur ein Servername. Der SharePoint-Bereich ist die GUID der lokalen SharePoint-Farm, auf die das Zugriffstoken zugreift (oder die GUID des Mandanten, wenn die Farm für Mandanten konfiguriert wurde).

Ermitteln Sie den SharePoint-Bereich durch Ausführen des PowerShell-Get-SPAuthenticationRealm-Cmdlets auf dem SharePoint-Server, und verwenden Sie ihn direkt in Ihrem Code oder speichern Sie ihn in einer Konfigurationsdatei, wie z. B. dem Abschnitt app.Settings einer web.config-Datei, damit Ihr Code ihn lesen kann.

Alternativ kann Ihr Code den SharePoint-Bereich dynamisch zur Laufzeit durch Senden einer Authentifizierungsanforderung an SharePoint ermitteln. Ein Beispiel, wie dies bei verwaltetem Code funktioniert, finden Sie unter GetRealmFromTargetUrl-Methode in der Datei TokenHelper.cs (oder .vb).		 00000003-0000-0ff1-ce00-000000000000/MarketingSharePointServer@52aa6841-b76b-4ed4-a3d7-a259fce1dfa2
iss Abkürzung für "issuer". Sie stellt den Prinzipal dar, der das Token erstellt hat.

Das Format ist Herausgeber- GUID@SharePoint-Bereichs-GUID. Im besonders vertrauenswürdigen System ist das Add-In selbst der Aussteller, sodass normalerweise die Client-ID des SharePoint-Add-In als Aussteller-GUID verwendet wird.

Alle Buchstaben in der Herausgeber-ID müssen kleingeschrieben sein.		 c3ab8885-458f-4864-8804-1608145e2ac4@52aa6841-b76b-4ed4-a3d7-a259fce1dfa2
nbf Abkürzung für "not before". Sie steht für den Zeitpunkt in Sekunden ab dem 1. Januar 1970 um Mitternacht, ab dem das Token beginnt, gültig zu werden. Ihr Code sollte dies auf dem Moment festgelegt, an dem das Token erstellt wird. 1403212820
exp Abkürzung für "expiration". Es stellt den Zeitpunkt dar, zu dem das Token abläuft, in Sekunden seit Mitternacht, dem 1. Januar 1970. 1403256020
nameid Ein eindeutiger Bezeichner für den Benutzer, für den das Token ausgestellt wurde. Das Format ist je nach Identitätsanbieter unterschiedlich. In diesem Beispiel ist der Anbieter Active Directory. s-1-5-21-2127521184-1604012920-1887927527-2963467
nii Abkürzung für "name identifier issuer". Der eindeutige Name des Identitätsanbieters wie er bei der Internet Assigned Numbers Authority (IANA) registriert ist. Bei einem besonders vertrauenswürdigen SharePoint-Add-In ist es normalerweise ein lokaler Identitätsanbieter wie Active Directory in diesem Beispiel. urn:office:idp:activedirectory
actortoken Ein Base64-codiertes JWT-Token, das das SharePoint-Add-In identifiziert und SharePoint mitteilt, dem Add-In zu vertrauen, unabhängig davon, welcher Benutzer das Add-In ausführt. Siehe unten.

Nachfolgend wird das decodierte Akteurtoken dargestellt. Das kleine JavaScript Object Notation (JSON)-Kopfzeilenobjekt oben enthält Metadaten über das Token, einschließlich dem Tokentyp und dem Algorithmus, der zum Signieren verwendet wird. Die x5t-Eigenschaft der Kopfzeile ist ein Digest aus dem Fingerabdruck des X.509-Zertifikats, das offiziell der Herausgeber des Tokens ist. Um diesen Wert zu erstellen, geht der Code folgendermaßen vor:

  1. Er ruft die Bytearray-Version (keine Zeichenfolge) des Fingerabdrucks des Zertifikats ab. Dies ist ein SHA-1-Digest des Zertifikats. (Bei verwaltetem Code kann dies mit der GetCertHash()-Methode erfolgen. Sie benötigen eine Entsprechung in der Sprache, die Sie verwenden.)

  2. Codiertes Bytearray mit Base64-URL-Codierung.

  3. Legen Sie den Wert der Eigenschaft x5t auf den codierten Digest fest.

Tabelle 2 beschreibt die Ansprüche, die der Code im Hauptteil des Tokens einschließen muss, sowie die dafür festzulegenden Werte.

{"typ":"JWT","alg":"RS256","x5t":"7MjK99QvkVdwz6UrKldx8AG7ydM"}
.
{
 "aud":"00000003-0000-0ff1-ce00-000000000000/MarketingServer@52aa6841-b76b-4ed4-a3d7-a259fce1dfa2",
 "iss":"11111111-1111-1111-1111-111111111111@52aa6841-b76b-4ed4-a3d7-a259fce1dfa2",
 "nbf":"1403212820",
 "exp":"1403256020",
 "nameid":"c3ab8885-458f-4864-8804-1608145e2ac4@52aa6841-b76b-4ed4-a3d7-a259fce1dfa2",
 "trustedfordelegation":"true"
}

Hinweis

Wenn das Add-In mit hoher Vertrauenswürdigkeit die Richtlinie Nur-Add-In verwendet und einen Nur-Add-In Aufruf an SharePoint durchführt, ist das hier gezeigte Token tatsächlich das Zugriffstoken. Es gibt kein äußeres Token. Darüber hinaus gibt es keinen trustedfordelegation-Anspruch, da die Berechtigungen des Benutzers für einen Nur-Add-In-Aufruf nicht relevant sind.

Tabelle 2: Akteurtoken-Ansprüche mit ausgestelltem Zertifikat

Anspruch Beschreibung Entsprechender Wert im Beispielzugriffstoken
aud Wie im übergeordneten Zugriffstoken. 00000003-0000-0ff1-ce00-000000000000/MarketingSharePointServer@52aa6841-b76b-4ed4-a3d7-a259fce1dfa2
iss Dieselbe Bedeutung wie im übergeordneten Zugriffstoken, aber die Herausgeber-GUID ist nicht die Client-ID der Webanwendung. Es ist die GUID des Zertifikats.

Obwohl der Code in der Anwendung das Akteurtoken erstellt, wird das Zertifikat als Herausgeber des Akteuertokens betrachtet.

Beachten Sie, dass die Herausgeber-GUID in diesem Beispiel eine leicht zu merkende GUID-Zeichenfolge ist, die der Farmadministrator verwendet hat, als er das X.509-Zertifikat als vertrauenswürdiger Token-Herausgeber in SharePoint registriert hat. Dies ist häufig der Fall, wenn das gleiche Zertifikat als Akteurtoken-Herausgeber für alle Add-Ins mit hoher Vertrauenswürdigkeit der Farm verwendet wird.

Ein Administrator kann auch auswählen, eindeutige Zertifikate für jedes SharePoint-Add-In zu registrieren. In diesem Fall würde er verschiedene zufällig generierte GUIDs für die Zertifikate verwenden.

Alle Buchstaben in der Herausgeber-ID müssen kleingeschrieben sein.		 11111111-1111-1111-1111-111111111111@52aa6841-b76b-4ed4-a3d7-a259fce1dfa2
nbf Dieselbe Bedeutung wie im übergeordneten Zugriffstoken. Derselbe Wert wie im übergeordneten Zugriffstoken.
exp Dieselbe Bedeutung wie im übergeordneten Zugriffstoken. Derselbe Wert wie im übergeordneten Zugriffstoken.
nameid Ein eindeutiger Bezeichner für das SharePoint-Add-In, da es der "actor" im besonders vertrauenswürdigen System ist. Das Format ist Client_ID@SharePoint_realm. c3ab8885-458f-4864-8804-1608145e2ac4@52aa6841-b76b-4ed4-a3d7-a259fce1dfa2
trustedfordelegation Ein boolescher Wert, der angibt, ob SharePoint dem SharePoint-Add-In vertrauen sollte, dass sie den Benutzer authentifiziert und autorisiert. Im besonders vertrauenswürdigen System ist der Wert normalerweise "Keine". Integrieren Sie diesen Anspruch nicht in einen Nur-Add-In-Aufruf im besonders vertrauenswürdigen System. true

Codieren und Signieren von Token

Nachdem Ihr Code alle Eigenschaften und Werte zu Header- und Hauptteil-JSON-Objekten hinzugefügt hat, muss er sie codieren, in ein JWT kombinieren und signieren. Die einzelnen Schritte sind im Folgenden aufgeführt.

  1. Codieren Sie den Header mit der Base64-URL-Codierung.
  2. Codieren Sie die Nutzlast mit der Base64-URL-Codierung.
  3. Verknüpfen Sie den codierten Hauptteil nach dem codierten Header mit einem "."-Zeichen dazwischen. Dies ist das JWT.
  4. Erstellen Sie eine SHA256-Signatur mit dem JWT und dem privaten Schlüssel des Zertifikats.
  5. Codieren Sie die Signatur mit der Base64-URL-Codierung.
  6. Fügen Sie die Signatur an das Ende von JWT an, und fügen Sie dazwischen einen Punkt („.“) ein.

Bei einem Akteurtoken, das mit einem Nur-Add-In-Aufruf verwendet wird, dient das Akteurtoken als Zugriffstoken. Es gibt kein äußeres Token. Für ein Zugriffstoken, das mit einem Benutzer-Add-In-Aufruf verwendet wird, werden die oben genannten Schritte verwendet, um ein Akteurtoken zu erstellen, das dann in den Text eines Zugriffstokens als Wert der Akteurtoken-Eigenschaft eingesetzt wird. Das vollständige Zugriffstoken wird dann codiert und mit den ersten drei Schritten oben erstellt, aber es ist nicht signiert, sodass die verbleibenden Schritte nicht für das äußere Token verwendet werden.

Problembehandlung bei Zugriffstoken

Das kostenlose Fiddler-Tool kann zum Erfassen der HTTP-Anforderungen verwendet werden, die von der Remotekomponente Ihres Add-Ins an SharePoint gesendet werden. Es gibt eine kostenlose Erweiterung für dieses Tool, die automatisch die Token in den Anforderungen decodiert.

Siehe auch