Zum Hauptinhalt springen

4. JSON Web Token Claims und Introspektionsantwortparameter

Es ist nützlich, Mechanismen definiert zu haben, um Delegierung innerhalb eines Tokens auszudrücken sowie die Autorisierung zur Delegierung oder zum Identitätswechsel auszudrücken. Obwohl das hier beschriebene Token-Austauschprotokoll mit jeder Art von Token verwendet werden kann, definiert dieser Abschnitt Claims, um solche Semantiken spezifisch für JWTs und in einer OAuth 2.0 Token Introspektion [RFC7662]-Antwort auszudrücken. Ähnliche Definitionen für andere Arten von Tokens sind möglich, liegen jedoch außerhalb des Geltungsbereichs dieser Spezifikation.

Beachten Sie, dass die hier nicht festgelegten, aber in Beispielen und Beschreibungen verwendeten Claims, wie "iss", "sub", "exp" usw., durch [JWT] definiert sind.

4.1. "act" (Actor) Claim​

Der "act" (Akteur)-Claim bietet innerhalb eines JWT ein Mittel, um auszudrücken, dass eine Delegierung stattgefunden hat, und die handelnde Partei zu identifizieren, an die Autorität delegiert wurde. Der Wert des "act"-Claims ist ein JSON-Objekt, und Mitglieder im JSON-Objekt sind Claims, die den Akteur identifizieren. Die Claims, die den "act"-Claim bilden, identifizieren den Akteur und liefern möglicherweise zusätzliche Informationen über ihn. Zum Beispiel könnte die Kombination der beiden Claims "iss" und "sub" notwendig sein, um einen Akteur eindeutig zu identifizieren.

Claims innerhalb des "act"-Claims beziehen sich jedoch nur auf die Identität des Akteurs und sind für die Gültigkeit des enthaltenden JWT nicht in derselben Weise relevant wie die Top-Level-Claims. Folglich sind Nicht-Identitäts-Claims (z. B. "exp", "nbf" und "aud") nicht sinnvoll, wenn sie innerhalb eines "act"-Claims verwendet werden, und werden daher nicht verwendet.

Abbildung 5 illustriert den "act" (Akteur)-Claim innerhalb eines JWT Claims Sets. Die Claims des Tokens selbst handeln von [email protected], während der "act"-Claim angibt, dass [email protected] der aktuelle Akteur ist.

{
  "aud":"https://consumer.example.com",
  "iss":"https://issuer.example.com",
  "exp":1443904177,
  "nbf":1443904077,
  "sub":"[email protected]",
  "act":
  {
    "sub":"[email protected]"
  }
}

Abbildung 5: Actor Claim

Eine Delegierungskette kann ausgedrückt werden, indem ein "act"-Claim innerhalb eines anderen verschachtelt wird. Der äußerste "act"-Claim repräsentiert den aktuellen Akteur, während verschachtelte "act"-Claims frühere Akteure repräsentieren. Der am wenigsten aktuelle Akteur ist am tiefsten verschachtelt. Die verschachtelten "act"-Claims dienen als Verlaufspfad, der die ursprüngliche Anforderung und das Subjekt durch die verschiedenen Delegierungsschritte verbindet, die unternommen wurden, bevor der aktuelle Akteur erreicht wurde. In diesem Sinne wird der aktuelle Akteur so betrachtet, dass er die gesamte Autorisierungs-/Delegierungshistorie einschließt, was natürlich zu der hier beschriebenen verschachtelten Struktur führt.

Zum Zwecke der Anwendung von Zugriffskontrollrichtlinien MUSS der Konsument eines Tokens nur die Top-Level-Claims des Tokens und die Partei berücksichtigen, die durch den "act"-Claim als der aktuelle Akteur identifiziert wird. Durch beliebige verschachtelte "act"-Claims identifizierte frühere Akteure sind rein informativ und bei Zugriffskontrollentscheidungen nicht zu berücksichtigen.

Das folgende Beispiel in Abbildung 6 illustriert verschachtelte "act" (Akteur)-Claims innerhalb eines JWT Claims Sets. Die Claims des Tokens selbst handeln von [email protected], während der "act"-Claim angibt, dass das System <https://service16.example.com> der aktuelle Akteur ist und <https://service77.example.com> ein früherer Akteur war. Ein solches Token könnte als Ergebnis davon entstehen, dass service16 ein Token in einem Aufruf von service77 empfängt und es gegen ein für den Aufruf von service26 geeignetes Token eintauscht, während der Autorisierungsserver die Situation im neu ausgestellten Token vermerkt.

{
  "aud":"https://service26.example.com",
  "iss":"https://issuer.example.com",
  "exp":1443904100,
  "nbf":1443904000,
  "sub":"[email protected]",
  "act":
  {
    "sub":"https://service16.example.com",
    "act":
    {
      "sub":"https://service77.example.com"
    }
  }
}

Abbildung 6: Verschachtelter Actor Claim

Wenn "act" als Top-Level-Mitglied einer OAuth Token Introspektionsantwort enthalten ist, hat es dieselbe Semantik und dasselbe Format wie der gleichnamige Claim.

4.2. "scope" (Scopes) Claim​

Der Wert des "scope"-Claims ist eine JSON-Zeichenfolge, die eine durch Leerzeichen getrennte Liste von mit dem Token assoziierten Geltungsbereichen enthält, in dem in Abschnitt 3.3 von [RFC6749] beschriebenen Format.

Abbildung 7 illustriert den "scope"-Claim innerhalb eines JWT Claims Sets.

{
  "aud":"https://consumer.example.com",
  "iss":"https://issuer.example.com",
  "exp":1443904177,
  "nbf":1443904077,
  "sub":"dgaf4mvfs75Fci_FL3heQA",
  "scope":"email profile phone address"
}

Abbildung 7: Scopes Claim

OAuth 2.0 Token Introspektion [RFC7662] definiert bereits den Parameter "scope", um die mit dem Token assoziierten Geltungsbereiche zu übermitteln.

4.3. "client_id" (Client Identifier) Claim​

Der "client_id"-Claim trägt den Client-Identifier des OAuth 2.0 [RFC6749]-Clients, der das Token angefordert hat.

Das folgende Beispiel in Abbildung 8 illustriert den "client_id"-Claim innerhalb eines JWT Claims Sets, der einen OAuth 2.0-Client mit "s6BhdRkqt3" als dessen Identifier angibt.

{
  "aud":"https://consumer.example.com",
  "iss":"https://issuer.example.com",
  "exp":1443904177,
  "sub":"[email protected]",
  "client_id":"s6BhdRkqt3"
}

Abbildung 8: Client Identifier Claim

OAuth 2.0 Token Introspektion [RFC7662] definiert bereits den Parameter "client_id" als den Client-Identifier für den OAuth 2.0-Client, der das Token angefordert hat.

4.4. "may_act" (Authorized Actor) Claim​

Der "may_act"-Claim trifft eine Aussage, dass eine Partei autorisiert ist, der Akteur zu werden und im Namen einer anderen Partei zu handeln. Der Claim könnte beispielsweise verwendet werden, wenn ein "subject_token" in einer Token-Austauschanforderung dem Token-Endpunkt präsentiert wird, und der "may_act"-Claim im Subjekt-Token kann vom Autorisierungsserver verwendet werden, um zu bestimmen, ob der Client (oder die im "actor_token" identifizierte Partei) autorisiert ist, die angeforderte Delegierung oder den Identitätswechsel vorzunehmen.

Der Claim-Wert ist ein JSON-Objekt, und Mitglieder im JSON-Objekt sind Claims, die die Partei identifizieren, von der behauptet wird, dass sie berechtigt ist, für die durch das den Claim enthaltende JWT identifizierte Partei zu handeln. Die Claims, die den "may_act"-Claim bilden, identifizieren den autorisierten Akteur und liefern möglicherweise zusätzliche Informationen über ihn. Zum Beispiel ist die Kombination der beiden Claims "iss" und "sub" manchmal notwendig, um einen autorisierten Akteur eindeutig zu identifizieren, während der "email"-Claim verwendet werden könnte, um zusätzliche nützliche Informationen über diese Partei bereitzustellen.

Claims innerhalb des "may_act"-Claims beziehen sich jedoch nur auf die Identität dieser Partei und sind für die Gültigkeit des enthaltenden JWT nicht in derselben Weise relevant wie Top-Level-Claims. Folglich sind Claims wie "exp", "nbf" und "aud" nicht sinnvoll, wenn sie innerhalb eines "may_act"-Claims verwendet werden, und werden daher nicht verwendet.

Abbildung 9 illustriert den "may_act"-Claim innerhalb eines JWT Claims Sets. Die Claims des Tokens selbst handeln von [email protected], während der "may_act"-Claim angibt, dass [email protected] autorisiert ist, im Namen von [email protected] zu handeln.

{
  "aud":"https://consumer.example.com",
  "iss":"https://issuer.example.com",
  "exp":1443904177,
  "nbf":1443904077,
  "sub":"[email protected]",
  "may_act":
  {
    "sub":"[email protected]"
  }
}

Abbildung 9: Authorized Actor Claim

Wenn "may_act" als Top-Level-Mitglied einer OAuth Token Introspektionsantwort enthalten ist, hat es dieselbe Semantik und dasselbe Format wie der gleichnamige Claim.

Letztes Update am