Diese Dokumentation wurde archiviert und wird nicht länger gepflegt.

SWT (Simple Web Token)

Letzte Aktualisierung: Juni 2015

Dieser Artikel aus 2009 wurde als Vorschlag für einen Standard für SWT (Simple Web Token) für die IETF (Internet Engineering Task Force) entworfen. Er ist zwar nicht vollständig und stellt kein Hilfethema dar, bietet jedoch interessante Informationen über Format und Verwendung von SWT-Token.

Version 0.9.5.1, 04. November 2009

Simple Web Token (SWT) stellt ein Format zum Übertragen einer Bestätigung (Assertion) zwischen zwei Parteien zur Verfügung. Die Assertion stellt einen Satz von Name/Wert-Paaren dar, die als HTML-Formular codiert sind, und die Assertion der sich ergebenden Zeichenfolge erfolgt dann durch einen SHA 256-HMAC, der einen beiden Parteien gemeinsamen Schlüssel verwendet.

  • Dick Hardt (dick.hardt@microsoft.com), Redaktion

  • Yaron Goland (yarong@microsoft.com)

Diese Spezifikation steht unter dem Open Web Foundation Agreement, Version 0.9, unter [http://groups.google.com/group/open-web-board/web/owf-agreement-for-final-specs---pt-9-draft] zur Verfügung. [Hinweis: aktuelle URL steht aus.]Sie können die signierten Kopien des Open Web Foundation Agreement, Version 0.9, für diese Spezifikation unter [Speicher-URI des Gruppenvertrags einfügen] ansehen, die außerdem weitere als die oben aufgelisteten Parteien enthalten können. Ihre Nutzung dieser Spezifikation berührt möglicherweise die Rechte anderer dritter Parteien. DIESE SPEZIFIKATION WIRD "WIE BESEHEN" ZUR VERFÜGUNG GESTELLT. Die Verfasser schließen ausdrücklich jegliche Garantien (ausdrücklich, konkludent oder anderer Art), einschließlich der implizierten Garantien der Marktgängigkeit, Rückwirkungsfreiheit, Eignung für einen bestimmten Zweck oder des Titels im Zusammenhang mit der Spezifikation aus. Das Risiko der Implementierung oder sonstigen Verwendung der Spezifikation liegt vollständig beim Implementierenden und Nutzer der Spezifikation. UNTER KEINEN UMSTÄNDEN IST EINE PARTEI EINER ANDEREN PARTEI GEGENÜBER FÜR ENTGANGENE GEWINNE ODER ANDERE SCHÄDEN, SEIEN SIE INDIREKT, BESONDERS, ZUFÄLLIG ODER FOLGESCHÄDEN JEGLICHER ART AUS HANDLUNGEN JEGLICHER ART IM BEZUG AUF DIESE SPEZIFIKATION ODER DEN IHR ZUGRUNDELIEGENDEN VERTRAG HAFTBAR ZU MACHEN, WEDER AUF DER GRUNDLAGE VON VERTRAGSBRUCH, TORT; (EINSCHLIESSLICH FAHRLÄSSIGKEIT) ODER IN ANDERER WEISE UND UNABHÄNGIG DAVON, OB DIE ANDERE PARTEI ÜBER DIE MÖGLICHKEIT SOLCHER SCHÄDEN INFORMIERT WURDE ODER NICHT.

Simple Web Token (SWT) definiert ein Format zum Übertragen einer einfachen Assertion, die kompakt ist und ein Format aufweist, das eine einfache Aufnahme in einen Protokollheader, etwa von HTTP, ermöglicht. Eine einfache Assertion kann als Satz von Name/Wert-Paaren dargestellt werden. Als HTML-Formular codierte Werte entsprechen den Entwurfszielen, gut verstanden zu sein und ein sicheres Format für HTTP-Header darzustellen.

Da SWTs wichtige Identitäts- und Zugriffsinformationen übermitteln sollen, ist ein Verfahren zum Ausschließen von Manipulation erforderlich. Aus diesem Grund führen wir das einzig obligatorische Name/Wert-Paar in SWT ein – HMACSHA256. Dies ist immer das letzte Name/Wert-Paar in einem SWT, und der Wert ist der SHA 256-HMAC der anderen Name/Wert-Paare im SWT.

Die Wahl der anderen im SWT verwendeten Name/Wert-Paare liegt außerhalb des Bereichs dieser Spezifikation. Unter diesen Voraussetzungen gibt es eine Reihe von Bedingungen und Attributen, die ihre Nützlichkeit in einer Vielzahl von Assertionframeworks unter Beweis gestellt haben, insbesondere: Issuer (Aussteller), Audience (Zielgruppe) und ExpiresOn (AblaufAm). Zwar ist die Verwendung dieser Name/Wert-Paare nicht obligatorisch, wir definieren sie hier jedoch, um die Interoperabilität zu verbessern.

Schließlich erwarten wir, dass viele Attribute von Parteien erstellt werden, die SWTs austauschen. Wir verwenden Reverse-DNS-Namen, um die Erstellung neuer Attributnamen ohne Rücksicht auf Namenskonflikte zu vereinfachen. Wir unterstützen darüber hinaus auch die Verwendung von URIs als Namen. Namen, die weder Reverse-DNS-Namen noch URIs darstellen, sind private Namen, die durch eine Übereinkunft zwischen dem Ersteller und dem Nutzer des SWTs definiert sind und als solche Konflikten unterliegen können. Die in dieser Spezifikation definierten Namen sind reserviert.

Die in diesem Dokument verwendeten Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" müssen wie in [RFC2119] (Bradner, B., „Key words for use in RFCs to Indicate Requirement Levels“, [Schlüsselwörter für die Verwendung in RFCs zur Angabe von Anforderungsstufen]) beschrieben, interpretiert werden. Beispiele für Domänennamen verwenden [RFC2606] (Eastlake, D. und A. Panitz, „Reserved Top Level DNS Names“ [Reservierte DNS-Namen der obersten Ebene]).

Die Partei, die einen SWT erstellt, ist der Ersteller des SWTs. Die Partei, die einen SWT überprüft, ist der Nutzer der SWT. Vor dem Erstellen eines SWTs haben sich der Ersteller und der Nutzer auf die im SWT enthaltenen Attribute geeinigt und einen zufällig generierten 256-Bit-Schlüssel außerhalb des Bereichs ausgetauscht. Zum Erstellen eines SWT führt der Ersteller die folgenden Schritte aus:

  1. Die im SWT zu transportierenden Name/Wert-Paare werden gesammelt und als Formular als application/x-www-form-urlencoded gemäß 17.13.4 von HTML 4.01 codiert.

  2. Das als Formular codierte SWT und der vereinbarte Schlüssel werden dem SHA 256 HMAC-Prozess als Eingabe übergeben.

  3. Der resultierende HMAC-Wert wird übernommen und als Base64 gemäß Abschnitt 4 von RFC 4648 codiert.

  4. Entsprechend den Regeln zum Codieren von Formularen werden der Name "HMACSHA256" und der Base64-codierte HMAC-Wert am Ende des als Formular codierten SWTs hinzugefügt.

Der Nutzer eines SWTs führt die folgenden Schritte aus, um zu überprüfen, ob ein SWT vom Ersteller erstellt und nicht manipuliert wurde:

  1. Das übermittelte SWT wird angenommen und die Zeichenfolge in den Anteil vor “&HMACSHA256=” und den verbleibenden Teil aufgeteilt, bei dem es sich um den URL-codierten HMAC handelt. Der erste Teil ist "noHMACSWT".

  2. Der verbleibende Teil der SWT-Zeichenfolge wird URL-decodiert. Dies ist der "submittedHMAC".

  3. Für "noHMACSWT" wird mithilfe des vereinbarten Schlüssels ein HMAC generiert und anschließend als Base64 mit Base64-Codierung gemäß Abschnitt 4 von RFC 4648 codiert. Die resultierende Zeichenfolge ist "localHMAC".

  4. Ein zeichenweiser Vergleich von "submittedHMAC" und "localHMAC" wird durchgeführt. Wenn die Zeichenfolgen gleich sind, ist der HMAC des SWTs gültig.

Ein SWT-Ersteller möchte ein SWT mit den folgenden Informationen ausgeben:

Issuer = issuer.example.com
ExpiresOn = 1/1/2010, Midnight
com.example.group = gold
over18 = true

Mit einem HMAC-Schlüsselwert (in Base64-Darstellung) von:

N4QeKa3c062VBjnVK6fb+rnwURkcwGXh7EoNK34n0uM=

In diesem Beispiel sind "Issuer" und "ExpiresOn" reservierte Namen aus dieser Spezifikation. Das Attribut "com.example.group" ist eine akzeptierte Definition der Syntax und Semantik der vom Besitzer der Domäne "example.com" erstellten Gruppe. "over18" ist ein privat definiertes Attribut, auf das sich Ersteller und Nutzer des SWTs geeinigt haben.

Bevor wir das SWT codieren können, müssen wir für "ExpiresOn" die Anzahl der Sekunden vom 1.1.1970, Mitternacht UTC bis zum Zeitpunkt des Ablaufs am 1.1.2010 Mitternacht festlegen. Das Ergebnis ist 1262304000.

  1. Codieren Sie die Name/Wert-Paare in ein HTML-Formular. Das Ergebnis ist (die Zeilenwechsel wurden zwecks besserer Lesbarkeit eingefügt):

    Issuer=issuer.example.com&
    ExpiresOn=1262304000&
    com.example.group=gold&
    over18=true
    
  2. Berechnen Sie als Nächstes den HMAC des vorherigen Werts mithilfe des Schlüssels.

  3. Führen Sie eine Base64-Codierung des HMACs durch. Das Ergebnis ist:

    AT55+2jLQeuigpg0xm/vn7tjpSGXBUfFe0UXb0/9opE=
    
  4. Führen Sie eine URL-Codierung des resultierenden Base64-codierten HMACs durch, und fügen Sie ihn am Ende der Assertion an. Das resultierende SWT ist (die Zeilenwechsel wurden zwecks besserer Lesbarkeit eingefügt):

    Issuer=issuer.example.com&
    ExpiresOn=1262304000&
    com.example.group=gold&
    over18=true&
    HMACSHA256=
    AT55%2B2jLQeuigpg0xm%2Fvn7tjpSGXBUfFe0UXb0%2F9opE%3D
    

  1. Teilen Sie das SWT mithilfe von: &HMACSHA256= Wir erhalten diese noHMACSWT-Zeichenfolge (die Zeilenwechsel wurden zwecks besserer Lesbarkeit eingefügt):

    Issuer=issuer.example.com&
    ExpiresOn=1262304000&
    com.example.group=gold&
    over18=true&
    
    und die übermittelte submittedHMAC-Zeichenfolge:

    AT55%2B2jLQeuigpg0xm%2Fvn7tjpSGXBUfFe0UXb0%2F9opE%3D
    
  2. Als Nächstes wird eine URL-Decodierung von "submittedHMAC" durchgeführt, und das Ergebnis ist:

    AT55+2jLQeuigpg0xm/vn7tjpSGXBUfFe0UXb0/9opE=
    
  3. Anschließend berechnen wir den "localHMAC" mithilfe von "noHMACSWT" und dem HMAC-Schlüsselwert, führen eine Base64-Codierung des Ergebnisses durch, und erhalten den folgenden localHMAC-Wert:

    AT55+2jLQeuigpg0xm/vn7tjpSGXBUfFe0UXb0/9opE=
    
  4. Wir vergleichen "submittedHMAC" und "localHMAC" und stellen fest, dass es sich um die gleiche Zeichenfolge handelt. Anschließend führen wir die URL-Decodierung von "noHMACSWT" durch, um Zugang zu den SWT-Werten zu erhalten.

Die folgenden Name/Wert-Paare sind optional. Sie wurden definiert, um die Interoperabilität für viele häufige Szenarien zu verbessern, in denen sie hilfreich sind.

 

Name Wertsyntax Wertsemantik

Issuer

Eine UTF-8-Zeichenfolge

Identifiziert die Partei, die den SWT ausstellt.

ExpiresOn

Eine ASCII-Zeichenfolge, die eine ganze Zahl ohne Vorzeichen zur Basis 10 darstellt.

Identifiziert den Moment, in dem das SWT nicht mehr zur weiteren Verarbeitung angenommen werden darf.

Ablaufdatum und -uhrzeit sind als Anzahl der Sekunden aufgezeichnet, die von 1970-01-01T0:0:0Z bis zum Moment des Ablaufs, gemessen in UTC, verstreichen.

Zielgruppe

Eine UTF-8-Zeichenfolge

Identifiziert die SWT-Zielgruppe, für die das SWT bestimmt ist. Die Absicht dabei ist, dass beim Empfang eines SWTs durch einen SWT-Nutzer, das einen nicht zur SWT-Zielgruppe passenden Zielgruppenwert aufweist, das SWT zurückgewiesen werden muss.

Ein SWT-Ersteller darf einen Reverse-DNS-Namen oder einen URI zum Definieren zusätzlicher Attribute verwenden.

Ein Ersteller und ein Nutzer eines SWTs dürfen sich auf beliebige Attributnamen einigen, die nicht reserviert sind und keine öffentlichen Namen darstellen. Diese Namen dürfen nicht in der Liste der reservierten Namen vorkommen, die im Abschnitt "Reservierte Namen" oben definiert sind. Im Gegensatz zu öffentlichen Namen können diese privaten Namen zu Konflikten führen und sollten daher umsichtig eingesetzt werden.

Siehe auch

Anzeigen: