Freigeben über


Innenleben des Exchange-Identitätstokens

Wichtig

Legacy-Exchange-Token sind veraltet. Ab Februar 2025 werden wir ältere Exchange-Benutzeridentitäts- und Rückruftoken für Exchange Online Mandanten deaktivieren. Die Zeitleiste und Details finden Sie auf unserer Faq-Seite. Dies ist Teil der Secure Future Initiative von Microsoft, die Organisationen die Tools zur Verfügung stellt, die sie benötigen, um auf die aktuelle Bedrohungslandschaft zu reagieren. Exchange-Benutzeridentitätstoken funktionieren weiterhin für lokale Exchange-Instanzen. Die Authentifizierung geschachtelter Apps ist der empfohlene Ansatz für token in Zukunft.

Das Exchange-Benutzeridentitätstoken, das von der getUserIdentityTokenAsync-Methode zurückgegeben wird, bietet die Möglichkeit, dass Ihr Add-In-Code die Identität des Benutzers mit Aufrufen Ihres Back-End-Diensts einschließen kann. In diesem Artikel werden das Format und die Inhalte des Tokens erläutert.

Ein Exchange-Benutzeridentitätstoken ist eine base64-codierte URL-Zeichenfolge, die vom Exchange-Server signiert wird, von dem sie gesendet wurde. Das Token ist nicht verschlüsselt, und der öffentliche Schlüssel, den Sie zum Validieren der Signatur verwenden, wird auf dem Exchange-Server gespeichert, der das Token ausgegeben hat. Das Token besteht aus drei Teilen: einer Kopfzeile, einer Nutzlast und einer Signatur. In der Tokenzeichenfolge sind die Teile zur besseren Aufteilung des Tokens durch einen Punkt (.) voneinander getrennt.

Exchange verwendet das JSON-Webtokenformat (JWT) für das Identitätstoken. Informationen zu JWT-Token finden Sie unter RFC 7519 JSON-Webtoken (JWT).

Identitätstokenheader

Der Header stellt Informationen zum Format und Signaturinformationen des Tokens bereit. Im folgenden Beispiel wird gezeigt, wie der Header des Tokens aussieht.

{
  "typ": "JWT",
  "alg": "RS256",
  "x5t": "Un6V7lYN-rMgaCoFSTO5z707X-4"
}

In der folgenden Tabelle werden die Bestandteile des Tokenheaders beschrieben.
Anspruch Wert Beschreibung
typ JWT Identifiziert das Token als JSON-Webtoken. Alle Identitätstoken, die von Exchange-Server bereitgestellt werden, sind JWT-Token.
alg RS256 Der Hashalgorithmus, der zum Erstellen der Signatur verwendet wird. Alle vom Exchange-Server bereitgestellten Token verwenden den Hashalgorithmus „ RSASSA-PKCS1-v1_5 with SHA-256“.
x5t Zertifikatfingerabdruck Der X.509-Fingerabdruck des Tokens.

Identitätstokenlast

Die Last enthält die Authentifizierungsansprüche, mit denen das E-Mail-Konto und der Exchange-Server, der das Token gesendet hat, identifiziert werden. Das folgende Beispiel veranschaulicht den Abschnitt für die Last.

{ 
  "aud": "https://mailhost.contoso.com/IdentityTest.html", 
  "iss": "00000002-0000-0ff1-ce00-000000000000@mailhost.contoso.com", 
  "nbf": "1331579055", 
  "exp": "1331607855", 
  "appctxsender": "00000002-0000-0ff1-ce00-000000000000@mailhost.context.com",
  "isbrowserhostedapp": "true",
  "appctx": { 
    "msexchuid": "53e925fa-76ba-45e1-be0f-4ef08b59d389@mailhost.contoso.com",
    "version": "ExIdTok.V1",
    "amurl": "https://mailhost.contoso.com:443/autodiscover/metadata/json/1"
  } 
}

In der folgenden Tabelle werden die Bestandteile der Identitätstokenlast beschrieben.
Anspruch Beschreibung
aud Die URL des Add-Ins, die das Token angefordert hat. Ein Token ist nur gültig, wenn es von dem Add-In gesendet wird, das im Webview-Steuerelement des Clients ausgeführt wird. Die URL des Add-Ins wird im Manifest angegeben. Das Markup hängt vom Typ des Manifests ab.

Nur Add-In-Manifest: Wenn das Add-In das Office-Add-Ins-Manifestschema v1.1 verwendet, ist diese URL die URL, die im ersten <SourceLocation-Element> unter dem Formulartyp ItemRead oder ItemEditangegeben ist, je nachdem, was zuerst als Teil des FormSettings-Elements im Add-In-Manifest auftritt.

Einheitliches Manifest für Microsoft 365: Die URL wird in der Eigenschaft "extensions.audienceClaimUrl" angegeben.
iss Ein eindeutiger Bezeichner für den Exchange-Server, der das Token ausgestellt hat. Alle von diesem Exchange-Server ausgestellten Token weisen denselben Bezeichner auf.
nbf Das Datum und die Uhrzeit, ab dem das Token gültig ist. Der Wert ist die Anzahl der Sekunden seit dem 1. Januar 1970.
exp Das Datum und die Uhrzeit, bis das Token gültig ist. Der Wert ist die Anzahl der Sekunden seit dem 1. Januar 1970.
appctxsender Ein eindeutiger Bezeichner für den Exchange-Server, der den Anwendungskontext gesendet hat.
isbrowserhostedapp Gibt an, ob das Add-In in einem Browser gehostet wird.
appctx Der Anwendungskontext für das Token.

Die Informationen im appctx-Anspruch stellt den eindeutigen Bezeichner für das Konto und den Speicherort des öffentlichen Schlüssels bereit, das bzw. der zum Anmelden des Tokens verwendet wird. Die folgende Tabelle enthält die Teile des appctx-Elements.

Anwendungskontexteigenschaft Beschreibung
msexchuid Ein eindeutiger Bezeichner für das E-Mail-Konto und den Exchange-Server.
version Die Versionsnummer des Formulars. Der Wert für alle von Exchange bereitgestellten Token lautet ExIdTok.V1.
amurl Die URL des Dokuments mit den Authentifizierungsmetadaten, das den öffentlichen Schlüssel des X.509-Zertifikats enthält, das zur Signierung des Tokens verwendet wurde.

Weitere Informationen zur Verwendung des Dokuments mit den Authentifizierungsmetadaten finden Sie unter Überprüfen eines Exchange-Identitätstokens.

Identitätstokensignatur

Die Signatur wird erstellt durch das Hashing der Header- und Lastabschnitte mit dem im Header angegebenen Algorithmus und mithilfe des selbstsignierten X509-Zertifikats, das sich auf dem Server in dem für die Last angegebenen Speicherort befindet. Ihr Webdienst kann diese Signatur überprüfen, um sicherzustellen, dass das Identitätstoken von dem Server stammt, an den es gesendet werden soll.

Siehe auch

Ein Beispiel, dass das Exchange-Benutzeridentitätstoken analysiert, finden Sie unter Outlook-hinzufügen-In-Token-Viewer.