GenerateJWT-Richtlinie

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Was

Generiert ein signiertes JWT oder ein verschlüsseltes JWT mit einem konfigurierbaren Satz von Anforderungen. Das JWT kann dann an Clients zurückgegeben, an Backend-Ziele übertragen oder auf andere Weise genutzt werden. Eine detaillierte Einführung finden Sie unter Übersicht über JWS- und JWT-Richtlinien.

Diese Richtlinie ist eine erweiterbare Richtlinie, deren Verwendung je nach Apigee-Lizenz Auswirkungen auf die Kosten oder die Nutzung haben kann. Informationen zu Richtlinientypen und Auswirkungen auf die Nutzung finden Sie unter Richtlinientypen.

Wie

Ob die Richtlinie ein signiertes oder verschlüsseltes JWT generiert, hängt von dem Element ab, mit dem Sie den Algorithmus angeben, der das JWT generiert:

• Wenn Sie das Element <Algorithm> verwenden, generiert die Richtlinie ein signiertes JWT.
• Wenn Sie das Element <Algorithms> verwenden, generiert die Richtlinie ein verschlüsseltes JWT.

Video

Hinweis: Das folgende Video zeigt den klassischen Proxy-Editor in der Apigee-UI. Apigee führt eine neue Version des Proxy-Editors ein, die ein anderes Design als die im Video gezeigte klassische Version hat.

In diesem kurzen Video erfahren Sie, wie Sie ein signiertes JWT generieren.

Signiertes JWT generieren

In diesem Abschnitt wird erläutert, wie Sie ein signiertes JWT generieren. Verwenden Sie bei einem signierten JWT das Element <Algorithm>, um den Algorithmus zum Signieren des Schlüssels anzugeben.

Beispiele für ein signiertes JWT

In den folgenden Beispielen wird gezeigt, wie Sie ein signiertes JWT generieren.

HS256-Algorithmus

Diese Beispielrichtlinie generiert ein neues JWT und signiert es unter Einsatz des HS256-Algorithmus. HS256 stützt sich auf ein gemeinsames Secret für die Signatur und die Verifizierung der Signatur.

Wird diese Richtlinienaktion ausgelöst, so codiert Apigee den JWT-Header und die Nutzlast und signiert das JWT dann digital. Das Video oben zeigt ein umfassendes Beispiel, in dem auch beschrieben wird, wie Sie eine Anfrage an die Richtlinie senden.

Die Richtlinienkonfiguration erstellt in diesem Fall ein JWT mit einem Standardanforderungssatz, wie in der JWT-Spezifikation definiert, einschließlich einer Ablaufzeit von 1 Stunde sowie einer zusätzlichen Anforderung. Sie können beliebig viele zusätzliche Anforderungen hinzufügen. Details zu den Anforderungen und Optionen für die einzelnen Elemente in dieser Beispielrichtlinie finden Sie in der Elementreferenz.

<GenerateJWT name="JWT-Generate-HS256">
    <DisplayName>JWT Generate HS256</DisplayName>
    <Type>Signed</Type>
    <Algorithm>HS256</Algorithm>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <SecretKey>
        <Value ref="private.secretkey"/>
        <Id>1918290</Id>
    </SecretKey>
    <ExpiresIn>1h</ExpiresIn>
    <Subject>monty-pythons-flying-circus</Subject>
    <Issuer>urn://apigee-JWT-policy-test</Issuer>
    <Audience>fans</Audience>
    <Id/>
    <AdditionalClaims>
        <Claim name="show">And now for something completely different.</Claim>
    </AdditionalClaims>
    <OutputVariable>jwt-variable</OutputVariable>
</GenerateJWT>

Das resultierende JWT hat dann folgenden Header…

{
  "typ" : "JWT",
  "alg" : "HS256",
  "kid" : "1918290"
}

… und eine Nutzlast mit Inhalten wie diesem:

{
  "sub" : "monty-pythons-flying-circus",
  "iss" : "urn://apigee-JWT-policy-test",
  "aud" : "fans",
  "iat" : 1506553019,
  "exp" : 1506556619,
  "jti" : "BD1FF263-3D25-4593-A685-5EC1326E1F37",
  "show": "And now for something completely different."
}

Der Wert der Anforderungen iat, exp und jti variiert.

RS256-Algorithmus

Hinweis: Verwenden Sie dieses Beispiel auch, um ein JWT für den PS256- oder ES256-Algorithmus zu erstellen. Dazu ändern Sie einfach den Wert von <Algorithm>RS256</Algorithm> in PS256 oder ES256. Für ES256 müssen Sie auch einen mit dem Algorithmus kompatiblen Schlüssel angeben. Weitere Informationen zu den Schlüsselanforderungen finden sich unter Signaturverschlüsselungsalgorithmen.

Diese Beispielrichtlinie generiert ein neues JWT und signiert es unter Einsatz des RS256-Algorithmus. Das Generieren einer RS256-Signatur benötigt einen privaten RSA-Schlüssel, der in PEM-codierter Form bereitgestellt werden muss und mit Passwortverschlüsselung versehen sein kann. Das Video oben zeigt ein umfassendes Beispiel, in dem auch beschrieben wird, wie Sie eine Anfrage an die Richtlinie senden.

Wird diese Richtlinienaktion ausgelöst, so codiert Apigee das JWT und signiert es digital, einschließlich der Anforderungen. Informationen zu den Teilen eines JWT und deren Verschlüsselung und Signatur finden Sie unter RFC7519.

<GenerateJWT name="JWT-Generate-RS256">
    <Type>Signed</Type>
    <Algorithm>RS256</Algorithm>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <PrivateKey>
        <Value ref="private.privatekey"/>
        <Password ref="private.privatekey-password"/>
        <Id ref="private.privatekey-id"/>
    </PrivateKey>
    <Subject>apigee-seattle-hatrack-montage</Subject>
    <Issuer>urn://apigee-JWT-policy-test</Issuer>
    <Audience>urn://c60511c0-12a2-473c-80fd-42528eb65a6a</Audience>
    <ExpiresIn>60m</ExpiresIn>
    <Id/>
    <AdditionalClaims>
        <Claim name="show">And now for something completely different.</Claim>
    </AdditionalClaims>
    <OutputVariable>jwt-variable</OutputVariable>
</GenerateJWT>

In den obigen Beispielen wird das Element <Algorithm> verwendet, sodass ein signiertes JWT generiert wird. Das <PrivateKey>-Element gibt den kryptografischen Schlüssel an, der zum Signieren des JWT verwendet wird. Es gibt noch weitere Schlüsselelemente. Welche davon Sie verwenden, hängt vom Algorithmus ab, der durch den Wert von <Algorithm> angegeben wird, wie im nächsten Abschnitt beschrieben.

Schlüsselelemente für ein signiertes JWT festlegen

Verwenden Sie genau eines der folgenden Elemente, um den Schlüssel anzugeben, mit dem ein signiertes JWT generiert wird:

• <SecretKey>
• <PrivateKey>

Welches Element Sie verwenden, hängt vom ausgewählten Algorithmus ab, wie in der folgenden Tabelle dargestellt:

Hinweis: Die RS*-, PS*- und ES*-Algorithmen verwenden dieselben Elemente, um den Schlüssel anzugeben, aber die ES*-Schlüsseldaten unterscheiden sich von denjenigen, die von den RS*- und PS*-Algorithmen verwendet werden.

Algorithmus	Schlüsselelemente
HS{256/384/512}^*	<SecretKey> <Value ref="private.secretkey"/> <Id ref="secretkey-id">key-1918290</Id> </SecretKey>
RS/PS/ES{256/384/512}^*	<PrivateKey> <Value ref="private.privatekey"/> <Password ref="private.privatekey-password"/> <Id ref="privatekey-id">key-1918290</Id> </PrivateKey>

In den obigen Beispielen sind die Elemente <Password> und <Id> optional.

Weitere Informationen zu den Schlüsselanforderungen finden Sie unter Signaturverschlüsselungsalgorithmen.

Verschlüsseltes JWT generieren

In diesem Abschnitt wird erläutert, wie Sie ein verschlüsseltes JWT generieren. Verwenden Sie für ein verschlüsseltes JWT das Element <Algorithms>, um die Algorithmen zum Signieren des Schlüssels und des Inhalts anzugeben.

Beispiel für ein verschlüsseltes JWT

Im folgenden Beispiel wird gezeigt, wie ein verschlüsseltes JWT generiert wird. In diesem Beispiel wird das Element <Algorithms> verwendet, sodass ein verschlüsseltes JWT generiert wird.

RSA-OAEP-256

Im Beispiel unten gilt Folgendes:

• Der Schlüssel wird mit dem RSA-OAEP-256-Algorithmus verschlüsselt.
• Der Inhalt wird mit dem A128GCM-Algorithmus verschlüsselt.

Das <PublicKey>-Element gibt den Schlüssel für die Schlüsselverschlüsselung an.

<GenerateJWT name="gjwt-1">
  <Type>Encrypted</Type>
  <Algorithms>
    <Key>RSA-OAEP-256</Key>
    <Content>A128GCM</Content>
  </Algorithms>
  <PublicKey>
    <Value ref="rsa_publickey"/>
  </PublicKey>
  <Subject>[e-mail]</Subject>
  <Issuer>urn://apigee</Issuer>
  <ExpiresIn>1h</ExpiresIn>
  <AdditionalHeaders>
    <Claim name="moniker">Harvey</Claim>
  </AdditionalHeaders>
  <OutputVariable>output_var</OutputVariable>
</GenerateJWT>

A128KW

Im Beispiel unten gilt Folgendes:

• Der Schlüssel wird mit dem A128KW-Algorithmus verschlüsselt.
• Der Inhalt wird mit dem A128GCM-Algorithmus verschlüsselt.

Das <SecretKey>-Element gibt den Schlüssel für die Schlüsselverschlüsselung an.

<GenerateJWT name='gjwt-2'>
  <Algorithms>
    <Key>A128KW</Key>
    <Content>A128GCM</Content>
  </Algorithms>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <SecretKey>
    <Value ref='private.secretkey'/>
  </SecretKey>
  <Subject>[e-mail]</Subject>
  <Issuer>urn://apigee</Issuer>
  <ExpiresIn>1h</ExpiresIn>
  <OutputVariable>output_var</OutputVariable>
</GenerateJWT>

Schlüsselelemente für ein verschlüsseltes JWT festlegen

Verwenden Sie genau eines der folgenden Elemente, um den Verschlüsselungsschlüssel für GenerateJWT anzugeben, wenn Sie ein verschlüsseltes JWT generieren möchten:

• <PublicKey>
• <SecretKey>
• <PasswordKey>
• <DirectKey>

Welches Element Sie verwenden, hängt vom ausgewählten Schlüsselverschlüsselungsalgorithmus ab, wie in der folgenden Tabelle dargestellt:

Schlüsselverschlüsselungs-Algorithmus	Schlüsselelemente
RSA-OAEP-256	<PublicKey> <Value ref="rsa_publickey"/> </PublicKey> Hinweis: Der Schlüssel muss in einen öffentlichen RSA-Schlüssel aufgelöst werden.
ECDH-ES ECDH-ES+A128KW ECDH-ES+A192KW ECDH-ES+A256KW	<PublicKey> <Value ref="ec_publickey"/> </PublicKey> Hinweis: Der Schlüssel muss in einen öffentlichen Schlüssel mit Elliptische-Kurven-Auflösung aufgelöst werden.
A128KW A192KW A256KW A128GCMKW A192GCMKW A256GCMKW	<SecretKey> <Id>optional key identifier here</Id> <Value ref="private.secretkey"/> </SecretKey>
PBES2-HS256+A128KW PBES2-HS384+A192KW PBES2-HS512+A256KW	<PasswordKey> <Id>optional key identifier here</Id> <Value ref="private.passwordkey"/> <SaltLength> <PBKDF2Iterations> </PasswordKey>
dir	<DirectKey> <Id>optional key identifier here</Id> <Value encoding="base16|hex|base64|base64url" ref="private.directkey"/> </DirectKey>

Weitere Informationen zu den Schlüsselanforderungen finden Sie unter Signaturverschlüsselungsalgorithmen.

Elementreferenz für das JWT generieren

Die Richtlinienreferenz beschreibt die Elemente und Attribute der Richtlinie zur JWT-Generierung.

Hinweis: Die Konfiguration variiert je nach verwendetem Verschlüsselungsalgorithmus. Beispiele für Konfigurationen für bestimmte Anwendungsfälle finden Sie unter Beispiele für ein signiertes JWT oder Beispiel für ein verschlüsseltes JWT.

Attribute, die auf das oberste Element angewendet werden

<GenerateJWT name="JWT" continueOnError="false" enabled="true" async="false">

Die folgenden Attribute gelten für alle übergeordneten Richtlinienelemente.

Attribut	Beschreibung	Standard	Präsenz
name	Der interne Name der Richtlinie. Folgende Zeichen sind im Namen zulässig: A-Z0-9._\-$ %. Die Apigee-Benutzeroberfläche erzwingt jedoch zusätzliche Einschränkungen, z. B. das automatische Entfernen nicht alphanumerischer Zeichen. Optional können Sie das Element <displayname></displayname> verwenden, um die Richtlinie im Proxy-Editor der Apigee-Benutzeroberfläche mit einem anderen Namen in der natürlichen Sprache zu versehen.	–	Erforderlich
continueOnError	Legen Sie false fest, um einen Fehler zurückzugeben, wenn eine Richtlinie fehlschlägt. Dies ist für die meisten Richtlinien das erwartete Verhalten. Legen Sie true fest, damit die Ablaufausführung auch nach dem Fehlschlagen einer Richtlinie fortgesetzt wird.	false	Optional
Aktiviert	Legen Sie true fest, um die Richtlinie zu erzwingen. Legen Sie false fest, um die Richtlinie zu "deaktivieren". Die Richtlinie wird nicht erzwungen, selbst wenn sie mit einem Ablauf verknüpft ist.	true	Optional
async	Dieses Attribut wurde verworfen.	false	Veraltet

<DisplayName>

<DisplayName>Policy Display Name</DisplayName>

Wird zusätzlich zum Namensattribut verwendet, um die Richtlinie im Proxy-Editor der Apigee-Benutzeroberfläche mit einem anderen Namen in einer natürlichen Sprache zu versehen.

Standard	Wenn Sie dieses Element weglassen, wird der Wert des Namensattributs der Richtlinie verwendet.
Präsenz	Optional
Typ	String

<Algorithm>

<Algorithm>algorithm-here</Algorithm>

Gibt den kryptografischen Algorithmus an, der zum Signieren des Tokens verwendet wird. Verwenden Sie das Element <Algorithm>, um ein signiertes JWT zu generieren.

Hinweis: Verwenden Sie genau eines der Elemente <Algorithm> und <Algorithms>.

Standard	–
Präsenz	Optional: Entweder <Algorithm> oder <Algorithms>, ist erforderlich.
Typ	String
Zulässige Werte	HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384, PS512

<Algorithms>

<Algorithms>
    <Key>key-algorithm</Key>
    <Content>content-algorithm</Content>
</Algorithm>

Gibt die kryptografischen Algorithmen für die Schlüssel- und Inhaltsverschlüsselung an. Verwenden Sie das Element <Algorithms>, um ein verschlüsseltes JWT zu generieren.

Hinweis: Verwenden Sie genau eines der Elemente <Algorithm> und <Algorithms>.

Standard	–
Optional: Entweder <Algorithm> oder <Algorithms>, ist erforderlich.	Erforderlich
Typ	String

Untergeordnete Elemente von <Algorithms>

Die folgende Tabelle enthält eine allgemeine Beschreibung der untergeordneten Elemente von <Algorithms>:

Untergeordnetes Element	Erforderlich?	Beschreibung
<Key>	Erforderlich	Gibt den Verschlüsselungsalgorithmus für den Schlüssel an.
<Content>	Erforderlich	Gibt den Verschlüsselungsalgorithmus für den Inhalt an.

Schlüsselverschlüsselungs-Algorithmen

In der folgenden Tabelle sind die verfügbaren Algorithmen für die Schlüsselverschlüsselung aufgeführt.

Wert von <Key> (Schlüsselverschlüsselungsalgorithmus)	Schlüsselelement erforderlich
dir	<DirectKey>
RSA-OAEP-256	<PublicKey> (muss in einen öffentlichen RSA-Schlüssel aufgelöst werden)
A128KW A192KW A256KW A128GCMKW A192GCMKW A256GCMKW	<SecretKey>
PBES2-HS256+A128KW PBES2-HS384+A192KW PBES2-HS512+A256KW	<PasswordKey>
ECDH-ES ECDH-ES+A128KW ECDH-ES+A192KW ECDH-ES+A256KW	<PublicKey> (muss in einen öffentlichen Schlüssel mit Elliptische-Kurven aufgelöst werden)

Unter Verschlüsseltes JWT generieren finden Sie ein Beispiel, in dem der Schlüsselverschlüsselungsalgorithmus RSA-OAEP-256 ist. Sie verwenden das Element <PublicKey> mit Wert, der in einen öffentlichen RSA-Schlüssel aufgelöst wird.

Algorithmen für die Inhaltsverschlüsselung

Die folgenden Algorithmen (symmetrisch, AES-basiert) stehen für die Inhaltsverschlüsselung zur Verfügung:

• A128CBC-HS256
• A192CBC-HS384
• A256CBC-HS512
• A128GCM
• A192GCM
• A256GCM

Weitere Informationen zu all diesen Algorithmen finden Sie unter RFC7518.

<Audience>

<Audience>audience-here</Audience>

or:

<Audience ref='variable_containing_audience'/>

Die Richtlinie generiert ein JWT, das eine aud-Anforderung mit dem angegebenen Wert enthält. Diese Anforderung identifiziert die Empfänger, für die das JWT bestimmt ist. Dies ist eine der in RFC7519 genannten registrierten Anforderungen.

Standard	–
Präsenz	Optional
Typ	Array (eine Liste mit durch Kommas getrennten Werten)
Zulässige Werte	Alles, was die Zielgruppe identifiziert.

<AdditionalClaims/Claim>

<AdditionalClaims>
    <Claim name='claim1'>explicit-value-of-claim-here</Claim>
    <Claim name='claim2' ref='variable-name-here'/>
    <Claim name='claim3' ref='variable-name-here' type='boolean'/>
</AdditionalClaims>

or:

<AdditionalClaims ref='claim_payload'/>

Ermöglicht die Angabe zusätzlicher Name/Wert-Paare für Anforderungen in der Nutzlast des JWT. Sie können die Anforderung explizit als String, Zahl, booleschen Wert, Zuordnung oder Array angeben. Ein Map ist einfach eine Reihe von Name/Wert-Paaren.

Das Element <Claim> unterstützt das Feature zur dynamischen Stringersetzung mit dem Namen message templating, wenn type=map.

Default	–
Präsenz	Optional
Zulässige Werte	Jeder Wert, den Sie für eine zusätzliche Anforderung verwenden möchten. Sie können die Anforderung explizit als String, Zahl, booleschen Wert, Zuordnung oder Array angeben.

Das Element <Claim> verwendet die folgenden Attribute:

• name – (erforderlich) Der Name der Anforderung.
  Hinweis: In diesem Element dürfen Sie keinen der registrierten Anforderungsnamen verwenden. Die registrierten Anforderungen sind in RFC7519 angegeben. Dazu gehören: "iss", "sub", "aud", "iat", "exp", "nbf" und "jti".
• ref – (optional) Der Name einer Ablaufvariable. Falls vorhanden, verwendet die Richtlinie den Wert dieser Variable als Anforderung. Wenn sowohl ein ref-Attribut als auch ein expliziter Anforderungswert angegeben sind, ist der explizite Wert der Standardwert. Er wird verwendet, wenn die referenzierte Ablaufvariable nicht aufgelöst wird.
• type – (optional) Kann String (Standard), Zahl, boolescher Wert oder Map sein
• array – (optional) Legen Sie true fest, um anzugeben, dass der Wert ein Typarray ist. Standardeinstellung: false.

Wenn Sie das Element <Claim> hinzufügen, werden die Anforderungsnamen beim Konfigurieren der Richtlinie statisch festgelegt. Alternativ können Sie ein JSON-Objekt übergeben, um die Anforderungsnamen anzugeben. Da das JSON-Objekt als Variable übergeben wird, werden die Anforderungsnamen im generierten JWT zur Laufzeit bestimmt.

Beispiel:

<AdditionalClaims ref='json_claims'/>

Die Variable json_claims enthält ein JSON-Objekt im folgenden Format:

{
  "sub" : "[e-mail]",
  "iss" : "urn://[e-mail]",
  "non-registered-claim" : {
    "This-is-a-thing" : 817,
    "https://example.com/foobar" : { "p": 42, "q": false }
  }
}

Das generierte JWT enthält alle Anforderungen im JSON-Objekt.

Beachten Sie folgendes Verhalten im Hinblick auf die Verwendung einer Variablenreferenz und eines expliziten Anforderungswerts im Claim-Element:

Apigee generiert unter folgenden Bedingungen keine Anforderung:

• Wenn ein Variablenverweis vorhanden ist, aber nicht aufgelöst wird, und
• Wenn Sie keinen expliziten Wert (Standardwert) angeben.
• Wenn das Richtlinienattribut IgnoreUnresolvedVariables true ist.

Ist IgnoreUnresolvedVariables false, so löst Apigee unter den obigen Bedingungen einen Fehler aus.

Apigee generiert unter folgenden Bedingungen eine Anforderung:

• Wenn ein Variablenverweis vorhanden ist, aber nicht aufgelöst wird.
• Wenn Sie einen expliziten Wert (Standardwert) angeben.
• Wenn IgnoreUnresolvedVariables entweder true oder false ist.

<AdditionalHeaders/Claim>

<AdditionalHeaders>
    <Claim name='claim1'>explicit-value-of-claim-here</Claim>
    <Claim name='claim2' ref='variable-name-here'/>
    <Claim name='claim3' ref='variable-name-here' type='boolean'/>
    <Claim name='claim4' ref='variable-name' type='string' array='true'/>
 </AdditionalHeaders>

Fügt die zusätzlichen Paare aus Anforderungsname/Wert in den Header für die JWS ein.

Das Element <Claim> unterstützt das Feature zur dynamischen Stringersetzung mit dem Namen message templating, wenn type=map.

Default	–
Präsenz	Optional
Zulässige Werte	Jeder Wert, den Sie für eine zusätzliche Anforderung verwenden möchten. Sie können die Anforderung explizit als String, Zahl, booleschen Wert, Zuordnung oder Array angeben.

Das Element <Claim> verwendet die folgenden Attribute:

• name – (erforderlich) Der Name der Anforderung.
  Hinweis: In diesem Element dürfen Sie keinen der registrierten Anforderungsnamen verwenden. Die registrierten Anforderungen sind in RFC7519 angegeben. Dazu gehören: "iss", "sub", "aud", "iat", "exp", "nbf" und "jti".
• ref – (optional) Der Name einer Ablaufvariable. Falls vorhanden, verwendet die Richtlinie den Wert dieser Variable als Anforderung. Wenn sowohl ein ref-Attribut als auch ein expliziter Anforderungswert angegeben sind, ist der explizite Wert der Standardwert. Er wird verwendet, wenn die referenzierte Ablaufvariable nicht aufgelöst wird.
• type – (optional) Kann String (Standard), Zahl, boolescher Wert oder Map sein
• array – (optional) Legen Sie true fest, um anzugeben, dass der Wert ein Typarray ist. Standardeinstellung: false.

<Compress>

<Compress>true</Compress>

Gibt an, ob Text vor der Verschlüsselung komprimiert wird. Dieses Element ist nur gültig, wenn ein verschlüsseltes JWT generiert wird.

<CriticalHeaders>

<CriticalHeaders>a,b,c</CriticalHeaders>

or:

<CriticalHeaders ref=’variable_containing_headers’/>

Fügt dem JWT-Header den kritischen Header crit hinzu. Der Header crit ist ein Array aus Headernamen, die bekannt sein und vom JWT-Empfänger erkannt werden müssen. Beispiel:

{
  "typ": "...",
  "alg" : "...",
  "crit" : [ "a", "b", "c" ],
}

Gemäß der Spezifikation müssen überprüfende Parteien den crit-Header prüfen und überprüfen, ob jeder dieser Header verstanden wird. Beispielsweise prüft die VerifyJWT-Richtlinie den Header crit. Für jedes im crit-Header aufgeführte Element wird überprüft, ob das Element <KnownHeaders> der VerifyJWT-Richtlinie auch diesen Header enthält. Jeder Header, den die Richtlinie in crit findet, aber nicht in der <KnownHeaders>-Liste aufgeführt ist, lässt die VerifyJWT-Richtlinie fehlschlagen.

Hinweis: Mit <CriticalHeaders> werden die Header nicht in die JWT eingefügt. Dies definiert nur den Inhalt des crit-Headers. Sie können die Header mit <AdditionalHeader/Claims> hinzufügen.

Standard	–
Präsenz	Optional
Typ	Kommagetrenntes Stringarray
Zulässige Werte	Entweder ein Array oder der Name einer Variable, die das Array enthält.

<CustomClaims>

Hinweis: Derzeit wird ein CustomClaims-Element eingefügt, wenn Sie eine neue GenerateJWT-Richtlinie über die UI hinzufügen. Dieses Element ist nicht funktionsfähig und wird ignoriert. Das richtige zu verwendende Element ist <AdditionalClaims>. Die Benutzeroberfläche wird aktualisiert, sodass später die richtigen Elemente eingefügt werden.

<DirectKey>

<DirectKey>
  <Id>A12345</Id>
  <Value encoding="base16|hex|base64|base64url" ref="private.directkey"/>
</DirectKey>

Gibt einen direkten Schlüssel zum Verschlüsseln eines JWT an, wenn der Verschlüsselungsalgorithmus dir ist (direkte Verschlüsselung).

Untergeordnete Elemente von <DirectKey>

Die folgende Tabelle enthält eine allgemeine Beschreibung der untergeordneten Elemente von <DirectKey>:

Untergeordnetes Element	Erforderlich?	Beschreibung
ID	Optional	Schlüsselkennung
Wert	Erforderlich	Mit dem Attribut ref geben Sie einen Verweis auf eine Variable an. Der Inhalt der referenzierten Variable muss eine Stringcodierung eines Byte-Arrays sein, die über einen der folgenden Hexadezimal-Zeichen (base16), base64 oder base64url codiert ist.

Mit der direkten Schlüsselverschlüsselung können Sie eine Reihe von Byte direkt angeben, die als Content Encryption Key (CEK) fungieren. Sie müssen das Byte-Array als codierten String angeben. Die erforderliche Länge des Byte-Arrays hängt von der Stärke des ausgewählten Algorithmus für die Inhaltsverschlüsselung ab. Für A256CBC-HS512 müssen Sie beispielsweise einen Schlüssel mit genau 512 Bit oder 64 Byte bereitstellen.

Der Inhalt der Variable private.directkey muss ein String sein, der entweder über Hexadezimal (base16), base64 oder base64url codiert ist. Hier sehen Sie beispielsweise einen Hex-codierten 32-Byte-Schlüssel:

96 4b e1 71 15 71 5f 87 11 0e 13 52 4c ec 1e ba df 47 62 1a 9d 3b f5 ad d2 7b b2 35 e7 d6 17 11

Für die Hex-Codierung wird ein Leerzeichen akzeptiert, aber nicht erforderlich. Die Groß- oder Kleinschreibung wird akzeptiert (B7 ist mit b7 identisch).

Das Base64url-codierte Äquivalent des obigen ist:

lkvhcRVxX4cRDhNSTOweut9HYhqdO/Wt0nuyNefWFxE

Bei den base64*-Varianten wird das Leerzeichen nicht akzeptiert und die Groß-/Kleinschreibung wird berücksichtigt. Wenn Sie keine Codierung angeben, geht die Richtlinie davon aus, dass die Codierung base64 ist.

Im Folgenden wird die Länge der erforderlichen Schlüssel beschrieben:

Algorithmus zur Inhaltsverschlüsselung	Schlüssellänge erforderlich
A128CBC-HS256	256 Bit (32 Byte)
A192CBC-HS384	384 (48)
A256CBC-HS512	512 (64)
A128GCM	128 (16)
A192GCM	192 (24)
A256GCM	256 (32)

Hinweis: Der über das Element <DirectKey> bereitgestellte Inhaltsverschlüsselungsschlüssel muss genau die richtige Länge für den angegebenen Algorithmus zur Inhaltsverschlüsselung haben. Für jeden anderen Schlüsselverschlüsselungsalgorithmus als dir generiert die Richtlinie einen zufälligen CEK mit der richtigen Länge. Für dir muss die Konfiguration jedoch explizit einen Schlüssel mit richtige Größe bereitstellen.

<ExpiresIn>

<ExpiresIn>time-value-here</ExpiresIn>

or:

<ExpiresIn ref='time-value-here'/>

Gibt die Lebensdauer des JWT in Millisekunden, Sekunden, Minuten, Stunden oder Tagen an. Geben Sie die Ablaufzeit entweder mit dem XML-Element oder mit dem Attribut "ref" an, aber nicht mit beiden.

Hinweis: Dies ist ein Zeitraum, kein absoluter Zeitwert. Die Menge kann ein einfacher numerischer Wert sein, der dann als Millisekunden interpretiert wird.

Standard	N/A
Präsenz	Optional
Typ	Integer
Zulässige Werte	Ein Wert oder ein Verweis auf eine Ablaufvariable, die den Wert enthält. Zeiteinheiten können so angegeben werden: ms = Millisekunden (Standard) s = Sekunden m = Minuten h = Stunden d = Tage Beispiel: ExpiresIn=10d entspricht einem ExpiresIn von 864.000 Sekunden.

<Id>

<Id>explicit-jti-value-here</Id>
 -or-
<Id ref='variable-name-here'/>
 -or-
<Id/>

Generiert ein JWT mit der spezifischen jti-Anforderung. Wenn der Textwert und das ref-Attribut beide leer sind, generiert die Richtlinie einen jti mit einer zufälligen UUID. Die Anforderung der JWT-ID (jti) ist eine eindeutige Kennung für das JWT. Weitere Informationen über jti finden Sie unter RFC7519.

Standard	–
Präsenz	Optional
Typ	String oder Verweis.
Zulässige Werte	Ein String oder der Name einer Ablaufvariablen, die die ID enthält.

<IgnoreUnresolvedVariables>

<IgnoreUnresolvedVariables>true|false</IgnoreUnresolvedVariables>

Setzen Sie diesen Wert auf "false", wenn die Richtlinie einen Fehler ausgibt, falls eine in der Richtlinie angegebene Variable, auf die verwiesen wird, nicht auflösbar ist. Setzen Sie diesen Wert auf "true", um alle nicht aufgelösten Variablen als leeren String zu behandeln (null).

Standard	False
Präsenz	Optional
Typ	Boolean
Zulässige Werte	"true" oder "false"

<Issuer>

<Issuer ref='variable-name-here'/>
<Issuer>issuer-string-here</Issuer>

Die Richtlinie generiert ein JWT, das eine Anforderung mit dem Namen iss, mit einem auf den angegebenen Wert gesetzten Wert enthält. Eine Anforderung, die den Aussteller des JWT identifiziert. Dies ist eine der registrierten Anforderungen, die in RFC7519 erwähnt werden.

Standard	–
Präsenz	Optional
Typ	String oder Verweis
Zulässige Werte	Alle

<NotBefore>

<!-- Specify an absolute time. -->
<NotBefore>2017-08-14T11:00:21-07:00</NotBefore>
 -or-
<!-- Specify a time relative to when the token is generated. -->
<NotBefore>6h</NotBefore>

Gibt die Uhrzeit an, zu der das Token gültig wird. Das Token ist bis zur angegebenen Zeit ungültig. Sie können entweder einen absoluten Zeitwert oder eine Zeit relativ zum Zeitpunkt der Generierung des Tokens angeben.

Standard	–
Präsenz	Optional
Typ	String
Zulässige Werte	Siehe unten.

Gültige Zeitwerte für das "NotBefore"-Element für absolute Zeitwerte

Name	Format	Beispiel
sortierbar	yyyy-MM-dd'T'HH:mm:ss.SSSZ	2017-08-14T11:00:21.269-0700
RFC 1123	EEE, dd MMM yyyy HH:mm:ss zzz	Mon, 14 Aug 2017 11:00:21 PDT
RFC 850	EEEE, dd-MMM-yy HH:mm:ss zzz	Monday, 14-Aug-17 11:00:21 PDT
ANCI-C	EEE MMM d HH:mm:ss yyyy	Mon Aug 14 11:00:21 2017

Geben Sie für relative Zeitwerte eine Ganzzahl und einen Zeitraum an. Beispiel:

• 10s
• 60m
• 12h

<OutputVariable>

<OutputVariable>jwt-variable</OutputVariable>

Gibt an, wo das von dieser Richtlinie generierte JWS platziert werden soll. Standardmäßig wird es in die Ablaufvariable jwt.POLICYNAME.generated_jwt eingefügt.

Standard	jwt.POLICYNAME.generated_jwt
Präsenz	Optional
Typ	String (Name einer Ablaufvariablen)

<PasswordKey>

<PasswordKey>
  <Id>abcdefg</Id>
  <Value ref="private.password"/>
  <SaltLength>8</SaltLength>
  <PBKDF2Iterations>10000</PBKDF2>
</PasswordKey>

Gibt einen Schlüssel zum Verschlüsseln eines JWT an, wenn der Verschlüsselungsalgorithmus einer der folgenden ist:

• PBES2-HS256+A128KW
• PBES2-HS384+A192KW
• PBES2-HS512+A256KW

Für jeden dieser Schlüsselalgorithmen müssen Sie ein Passwort, aus dem der Schlüsselverschlüsselungsschlüssel abgeleitet wird, über die Variable private.password im Element <Value ref="private.password"/> angeben.

Untergeordnete Elemente von <PasswordKey>

Die folgende Tabelle enthält eine allgemeine Beschreibung der untergeordneten Elemente von <PasswordKey>:

Untergeordnetes Element	Präsenz	Beschreibung
ID	Optional	Schlüsselkennung
Wert	Erforderlich	Gibt das Passwort an, das zum Generieren des Schlüsselverschlüsselungsschlüssels verwendet wurde. Verwenden Sie ein ref-Attribut und geben Sie eine Variable an, z. B. private.password.
SaltLength	Optional	Salt-Länge. Standardeinstellung: 8 Byte.
PBKDF2Iterations	Optional	PBKDF2-Ausführungsanzahl: Standard: 10.000.

<PrivateKey>

<PrivateKey>
  <Id ref="privatekey-id"/>
  <Value ref="private.pem-encoded-privatekey"/>
  <Password ref="private.privatekey-password"/>
</PrivateKey>

Gibt den privaten Schlüssel an, der beim Generieren eines signierten JWT verwendet werden soll. Die Algorithm ist eine Variante der RSA- oder elliptischen Kurve (EC) – entweder RS256/RS384/RS512, PS256/PS384/PS512 oder ES256/ES384/ES512

Untergeordnete Elemente von <PrivateKey>

In der folgenden Tabelle sind die untergeordneten Elemente von <PrivateKey> beschrieben:

Untergeordnetes Element	Präsenz	Beschreibung
ID	Optional	Die Schlüsselkennung. Der Wert kann ein beliebiger String sein. Sie können den Wert als Literaltextwert oder indirekt über eine Variablenreferenz mit dem Attribut ref angeben. Die Richtlinie enthält diese Schlüsselkennung als Anforderung kid im Header des generierten JWT.
Wert	Erforderlich	Ein PEM-codierter privater Schlüssel. Gibt den privaten Schlüssel an, der zum Signieren der Nutzlast verwendet wird. Verwenden Sie ein ref-Attribut und geben Sie eine Variable an, z. B. private.private-key. Wenn das Element <Algorithm> eine RSA-Variante enthält (entweder RS256/RS384/RS512 oder PS256/PS384/PS512), müssen Sie einen codierten privaten RSA-Schlüssel angeben. Wenn das Element <Algorithm> eine EC-Variante enthält, einen von ES256/ES384/ES512, müssen Sie für die entsprechende Kurve einen privaten Schlüssel für Elliptische-Kurven angeben.
Passwort	Optional	Falls erforderlich, geben Sie das Passwort an, das die Richtlinie zum Entschlüsseln des privaten Schlüssels verwenden soll. Verwenden Sie das Attribut ref, um das Passwort über eine Ablaufvariable zu übergeben. Hinweis: Sie müssen eine Ablaufvariable angeben. Apigee lehnt Richtlinienkonfigurationen, in denen das Passwort im Klartext angegeben wird, als ungültig ab. Die Ablaufvariable muss das Präfix „private” haben. z. B. private.mypassword.

<PublicKey>

<PublicKey>
  <!-- specify exactly one of the following -->
  <Value ref="variable-containing-encoded-publickey"/>
  <Value>PEM encoded public key</Value>
  <Certificate ref="variable-containing-encoded-x509-certificate"/>
  <Certificate>PEM encoded X509 certificate</Certificate>
  <JWKS>jwks-content</JWKS>
  <JWKS ref="variable-containing-jwks-content"/>
  <JWKS uri="variable-containing-jwks-content"/>
  <JWKS uriRef="variable-containing-uri"/>
</PublicKey>

Gibt den öffentlichen Schlüssel an, der beim Generieren eines verschlüsselten JWT verwendet werden soll. Der Key-Algorithmus ist eine Variante der RSA- oder elliptischen Kurve (EC) – RSA-OAEP-256, ECDH-ES, ECDH-ES+ A128KW, ECDH-ES+A192KW oder ECDH-ES+A256KW.

Untergeordnete Elemente von <PublicKey>

Geben Sie entweder Value, Certificate oder JWKS an. Wenn Sie JWKS angeben, müssen Sie auch Id angeben. In der folgenden Tabelle sind diese untergeordneten Elemente von <PublicKey> beschrieben:

Untergeordnetes Element	Beschreibung
Wert	Ein PEM-codierter öffentlicher Schlüssel. Gibt den öffentlichen Schlüssel an, mit dem die Richtlinie den Inhaltsverschlüsselungsschlüssel verschlüsseln soll. Sie können den Schlüssel wortweise oder indirekt über eine Variablenreferenz angeben. <PublicKey> <Value ref="public.publickey"/> </PublicKey> oder <PublicKey> <Value> -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw2kPrRzcufvUNHvTH/WW 2F73IyN....your key will vary....1jC0dwUD1lHV8MfUyRXmpmnNxJHACof C5TBtXMORc+us7A2cTtC4gZV256bT4h3sIEMsDl0Joz9K9MPzVPFxa1i0RgNt06n ZmkDb/DRW5onclGzxQITBFP3S6JXd4LNESJcTp705ec1cQ9Wp2Kl+nKrKyv1E5Xx DQIDAQAB -----END PUBLIC KEY----- </Value> </PublicKey> Der codierte öffentliche Schlüssel muss einen RSA-Schlüssel angeben, wenn Sie den Algorithmus RSA-OAEP-256 verwenden, oder einen EC-Schlüssel der entsprechenden Kurve, wenn Sie einen EC-Algorithmus verwenden.
Zertifikat	Ein PEM-codiertes X.509-Zertifikat, das einen öffentlichen Schlüssel verpackt. Apigee extrahiert den öffentlichen Schlüssel aus dem Zertifikat und verwendet diesen Schlüssel dann zum Verschlüsseln des Inhaltsverschlüsselungsschlüssels. Sie können das Zertifikat wortweise oder indirekt über eine Variablenreferenz angeben. <PublicKey> <Certificate ref="public.pem-encoded-certificate"/> </PublicKey> oder <PublicKey> <Certificate> -----BEGIN CERTIFICATE----- MIIDqDCCApACCQCG/xVb7Yzw3zANBgkqhkiG9w0BAQUFADCBlTELMAkGA1UEBhMC 2F73IyN....your certificate data will vary....1jC0dwUD1lHV8MfUyR VQQKDAZHb29nbGUxDzANBgNVBAsMBkFwaWdlZTEaMBgGA1UEAwwRYXBpZ2VlLmdv ... YjBaZuNUDVLGvbTSRgWG5lwm85Jar2zeCBcxFDwqyZFvVNV9SfoWF/LgVVpK54n8 rknZ17USb0ob51ckxPTENmF2DUHBzgptiw10Yw== -----END CERTIFICATE----- </Certificate> </PublicKey> Der codierte öffentliche Schlüssel muss einen RSA-Schlüssel angeben, wenn Sie den Algorithmus RSA-OAEP-256 verwenden, oder einen EC-Schlüssel der entsprechenden Kurve, wenn Sie einen EC-Algorithmus verwenden. Hinweis: Apigee validiert nicht die Gültigkeitsdaten in dem von Ihnen bereitgestellten Zertifikat und auch die Vertrauenskette auf dem Zertifikat wird nicht von Apigee validiert. Apigee behandelt alle Zertifikate, die Sie mit diesem Element angeben, als gültig und vertrauenswürdig.
JWKS	Eine JWKS-Quelle öffentlicher Schlüssel. Dies ist eine Liste der Schlüssel gemäß dem in IETF RFC 7517 – JSON Web Key (JWK) beschriebenen Format. Sie können das JWKS auf eine von vier Arten angeben: literal als Textwert: <PublicKey> <JWKS>jwks-content-here</JWKS> <Id ref="variable-containing-a-kid">literal-value-here</Id> </PublicKey> indirekt mit dem Attribut ref, das eine Ablaufvariable angibt: <PublicKey> <JWKS ref="variable-containing-jwks-content"/> <Id ref="variable-containing-a-kid">literal-value-here</Id> </PublicKey> Die referenzierte Variable sollte einen String enthalten, der einen JWKS darstellt. indirekt über einen statischen URI mit dem Attribut uri: <PublicKey> <JWKS uri="uri-that-returns-a-jwks"/> <Id ref="variable-containing-a-kid">literal-value-here</Id> </PublicKey> indirekt über einen dynamisch bestimmten URI mit dem Attribut uriRef: <PublicKey> <JWKS uriRef="variable-containing-a-uri-that-returns-a-jwks"/> <Id ref="variable-containing-a-kid">literal-value-here</Id> </PublicKey> Wenn Sie in JWKS ein Element im GenerateJWT angeben, müssen Sie auch das Element PublicKey/Id angeben. <PublicKey> <JWKS uri="uri-that-returns-a-jwks"/> <Id ref="variable-containing-a-kid">literal-value-here</Id> </PublicKey>
ID	Ein String, der die Schlüssel-ID darstellt. Zur Laufzeit ruft Apigee einen Schlüssel aus dem JWKS ab, der ein kid-Feld hat, das mit diesem Wert übereinstimmt. Das Element Id ist erforderlich, wenn Sie das Element JWKS in GenerateJWT verwenden.

<SecretKey>

<SecretKey encoding="base16|hex|base64|base64url" >
 <Id ref="variable-containing-key-id-here">secret-key-id</Id>
 <Value ref="private.variable-here"/>
</SecretKey>

Das SecretKey-Element ist optional. Es gibt den geheimen Schlüssel an, der beim Erstellen eines signierten JWT, das einen symmetrischen Algorithmus (HS*) verwendet, oder beim Erstellen eines verschlüsselten JWT, das einen symmetrischen Algorithmus (AES) für die Schlüsselverschlüsselung verwendet, angegeben werden soll.

Kinder von <SecretKey>

In der folgenden Tabelle sind die untergeordneten Elemente und Attribute von <SecretKey> beschrieben:

Untergeordnet	Präsenz	Beschreibung
encoding (Attribut)	Optional	Gibt an, wie der Schlüssel in der referenzierten Variable codiert ist. Wenn kein encoding-Attribut vorhanden ist, wird die Codierung des Schlüssels standardmäßig als UTF-8 behandelt. Gültige Werte für das Attribut sind: „hex“, „base16“, „base64“ und „base64url“. Die Codierungswerte „hex“ und „base16“ sind synonym. <SecretKey encoding="VALUE_HERE" > <Id ref="variable-containing-key-id-here">secret-key-id</Id> <Value ref="private.secretkey"/> </SecretKey> Wenn im obigen Beispiel das Codierungsattribut hex und der Inhalt der Variable private.secretkey 494c6f766541504973 ist, wird der Schlüssel als Satz von 9 Byte decodiert, was im Hexadezimalformat 49 4c 6f 76 65 41 50 49 73 ist. Umgekehrt, wenn das Codierungsattribut base64 und der Inhalt der Variable private.secretkey gleich VGhpcy1pcy1hLXNlY3JldA ist, wird der Schlüssel als Satz von 16 Byte decodiert, was im Hexadezimalformat 54 68 69 73 2d 69 73 2d 61 2d 73 65 63 72 65 74 ist. Hinweis: Apigee erzwingt eine Mindestschlüsselstärke. Weitere Informationen finden Sie in der Dokumentation zum Element Value.
Id (Element)	Optional	Die Schlüsselkennung. Der Wert kann ein beliebiger String sein. Sie können den Wert als Literaltextwert oder indirekt über eine Variablenreferenz mit dem Attribut ref angeben. <SecretKey> <Id ref="flow-variable-name-here"/> <Value ref="private.variable-here"/> </SecretKey> or <SecretKey> <Id>your-id-value-here</Id> <Value ref="private.variable-here"/> </SecretKey> Die Richtlinie enthält diese Schlüsselkennung als Anforderung kid im Header des generierten JWT.
Value (Element)	Erforderlich	Einen codierten geheimen Schlüssel Gibt den geheimen Schlüssel an, der zum Signieren der Nutzlast verwendet wird. Verwenden Sie das Attribut ref, um den Schlüssel indirekt über eine Variable wie private.secret-key bereitzustellen . <SecretKey> <Id ref="flow-variable-name-here"/> <Value ref="private.my-secret-variable"/> </SecretKey> Hinweis: Der Variablenname muss wie im Beispiel oben das private Präfix enthalten. Apigee erzwingt eine Mindestschlüsselstärke für die Algorithmen HS256/HS384/HS512. Die Mindestschlüssellänge für HS256 beträgt 32 Byte, für HS384 48 Byte und für HS512 64 Byte. Die Verwendung eines Schlüssels mit geringerer Stärke führt zu einem Laufzeitfehler.

<Subject>

<Subject>subject-string-here</Subject>

oder

<Subject ref="flow_variable" />

Beispiel:

<Subject ref="apigee.developer.email"/>

Die Richtlinie generiert ein JWT mit einem sub-Anspruch, der auf den angegebenen Wert gesetzt ist. Mit diesem Anspruch wird eine Aussage über das Subjekt des JWT identifiziert oder gemacht. Dies ist einer der Standardansprüche, die in IETF RFC 7519 erwähnt werden.

Default	–
Präsenz	Optional
Typ	String
Zulässige Werte	Jeder Wert, der eindeutig ein auf einen Wert verweisendes Subjekt oder eine solche Ablaufvariable identifiziert.

<Type>

<Type>type-string-here</Type>

Beschreibt, ob die Richtlinie ein signiertes oder ein verschlüsseltes JWT generiert. Das <Type>-Element ist optional. Sie können damit Leser über die Konfiguration informieren, unabhängig davon, ob die Richtlinie ein signiertes oder ein verschlüsseltes JWT generiert.

• Wenn das Element <Type> vorhanden ist:
  • Wenn der Wert von <Type> Signed lautet, generiert die Richtlinie ein signiertes JWT und das Element <Algorithm> muss vorhanden sein.
  • Wenn der Wert von <Type> Encrypted lautet, generiert die Richtlinie ein verschlüsseltes JWT und das Element <Algorithms> muss vorhanden sein.
• Wenn das Element <Type> nicht vorhanden ist:
  • Wenn das Element <Algorithm> vorhanden ist, geht die Richtlinie davon aus, dass <Type> den Wert Signed hat.
  • Wenn das Element <Algorithms> vorhanden ist, geht die Richtlinie davon aus, dass <Type> den Wert Encrypted hat.
• Wenn weder <Algorithm> noch <Algorithms> vorhanden ist, ist die Konfiguration ungültig.

Standard	–
Präsenz	Optional
Typ	String
Zulässige Werte	Signed oder Encrypted.

Ablaufvariablen

Die Richtlinie zum Generieren von JWTs legt keine Ablaufvariablen fest.

Fehlerreferenz

In diesem Abschnitt werden die zurückgegebenen Fehlercodes und Fehlermeldungen beschrieben, die von Apigee festgelegt werden, wenn die Richtlinie einen Fehler auslöst. Diese Informationen sind wichtig, wenn Sie Fehlerregeln zur Verarbeitung von Fehlern entwickeln. Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen und Fehler beheben.

Laufzeitfehler

Diese Fehler können bei Ausführung der Richtlinie auftreten.

Fehlercode	HTTP-Status	Tritt auf, wenn Folgendes eintritt
steps.jwt.AlgorithmInTokenNotPresentInConfiguration	401	Tritt auf, wenn die Prüfungsrichtlinie mehrere Algorithmen nutzt.
steps.jwt.AlgorithmMismatch	401	Der in der Generierungsrichtlinie angegebene Algorithmus stimmte nicht mit dem in der Verifizierungsrichtlinie erwarteten Algorithmus überein. Die angegebenen Algorithmen müssen übereinstimmen.
steps.jwt.EncryptionFailed	401	Das Erstellen eines verschlüsselten JWT ist aus einem nicht spezifischen Grund fehlgeschlagen.
steps.jwt.FailedToDecode	401	Die Richtlinie konnte das JWT nicht decodieren. Das JWT ist möglicherweise beschädigt.
steps.jwt.GenerationFailed	401	Die Richtlinie konnte das JWT nicht generieren.
steps.jwt.InsufficientKeyLength	401	Für einen Schlüssel mit weniger als 32 Byte beim HS256-Algorithmus, weniger als 48 Byte beim HS386 Algorithmus und weniger als 64 Byte beim HS512-Algorithmus.
steps.jwt.InvalidClaim	401	Bei fehlendem Anspruch, nicht übereinstimmender Anforderung oder fehlendem oder nicht übereinstimmendem Header.
steps.jwt.InvalidConfiguration	401	Sowohl das Element <Algorithm> als auch das Element <Algorithms> sind vorhanden.
steps.jwt.InvalidCurve	401	Die vom Schlüssel angegebene Kurve ist für den Elliptic-Curve-Algorithmus ungültig.
steps.jwt.InvalidJsonFormat	401	Ungültiger JSON-Code im Header oder der Nutzlast gefunden.
steps.jwt.InvalidPasswordKey	401	Der angegebene Schlüssel erfüllte nicht die Anforderungen.
steps.jwt.InvalidPrivateKey	401	Der angegebene Schlüssel erfüllte nicht die Anforderungen.
steps.jwt.InvalidPublicKey	401	Der angegebene Schlüssel erfüllte nicht die Anforderungen.
steps.jwt.InvalidSecretKey	401	Der angegebene Schlüssel erfüllte nicht die Anforderungen.
steps.jwt.InvalidToken	401	Dieser Fehler tritt auf, wenn die JWT-Signaturprüfung fehlschlägt.
steps.jwt.JwtAudienceMismatch	401	Der Zielgruppenanspruch ist bei der Tokenprüfung fehlgeschlagen.
steps.jwt.JwtIssuerMismatch	401	Der Ausstelleranspruch ist bei der Tokenprüfung fehlgeschlagen.
steps.jwt.JwtSubjectMismatch	401	Der Betreffanspruch ist bei der Tokenprüfung fehlgeschlagen.
steps.jwt.KeyIdMissing	401	Die Verifizierungsrichtlinie verwendet einen JWKS als Quelle für öffentliche Schlüssel, aber das signierte JWT hat kein kid-Attribut im Header.
steps.jwt.KeyParsingFailed	401	Der öffentliche Schlüssel konnte anhand der angegebenen Schlüsselinformationen nicht geparst werden.
steps.jwt.NoAlgorithmFoundInHeader	401	Tritt auf, wenn das JWT keinen Algorithmus-Header enthält.
steps.jwt.NoMatchingPublicKey	401	Die Verifizierungsrichtlinie verwendet einen JWKS als Quelle für öffentliche Schlüssel, aber kid im signierten JWT ist nicht in JWKS aufgeführt.
steps.jwt.SigningFailed	401	In GenerateJWT, für Schlüssel, die kleiner als die Mindestgröße für den HS384- oder HS512-Algorithmus sind
steps.jwt.TokenExpired	401	Die Richtlinie versucht, ein abgelaufenes Token zu bestätigen.
steps.jwt.TokenNotYetValid	401	Das Token ist noch nicht gültig.
steps.jwt.UnhandledCriticalHeader	401	Ein Header, der von der JWT-Richtlinie im Header crit gefunden wurde, ist nicht in KnownHeaders aufgeführt.
steps.jwt.UnknownException	401	Es ist eine unbekannte Ausnahme aufgetreten.
steps.jwt.WrongKeyType	401	Falscher Schlüsseltyp angegeben. Wenn Sie beispielsweise einen RSA-Schlüssel für einen Elliptic Curve-Algorithmus oder einen Kurvenschlüssel für einen RSA-Algorithmus angeben.

Bereitstellungsfehler

Diese Fehler können auftreten, wenn Sie einen Proxy mit dieser Richtlinie bereitstellen.

Tipp: Benötigen Sie Hilfe bei der Behebung eines Fehlers? Klicken Sie in der Spalte "Fehlerbehebung" auf , um detaillierte Informationen zur Fehlerbehebung aufzurufen.

Fehlername	Ursache	Beheben
InvalidNameForAdditionalClaim	Die Bereitstellung schlägt fehl, wenn der im untergeordneten Element <Claim> des Elements <AdditionalClaims> verwendete Anspruch einer der folgenden registrierten Namen ist: kid, iss, sub, aud, iat, exp, nbf oder jti.
InvalidTypeForAdditionalClaim	Wenn der verwendete Anspruch im untergeordneten Element <Claim> des Elements <AdditionalClaims> nicht vom Typ string, number, boolean oder map ist, schlägt die Bereitstellung fehl.
MissingNameForAdditionalClaim	Wenn der Name der Anforderung nicht im untergeordneten Element <Claim> des Elements <AdditionalClaims> angegeben ist, schlägt die Bereitstellung fehl.
InvalidNameForAdditionalHeader	Dieser Fehler tritt auf, wenn der Name des verwendeten Anspruchs im untergeordneten Element <Claim> des Elements <AdditionalClaims> entweder alg oder typ ist.
InvalidTypeForAdditionalHeader	Wenn die Art des verwendeten Anspruchs im untergeordneten Element <Claim> des Elements <AdditionalClaims> nicht zum Typ string, number, boolean oder map ist, schlägt die Bereitstellung fehl.
InvalidValueOfArrayAttribute	Dieser Fehler tritt auf, wenn der Wert des Arrayattributs im untergeordneten Element <Claim> des Elements <AdditionalClaims> nicht auf true oder false festgelegt ist.
InvalidConfigurationForActionAndAlgorithm	Wenn das Element <PrivateKey> mit HS-Family-Algorithmen oder das Element <SecretKey> mit RSA-Family-Algorithmen verwendet wird, schlägt die Bereitstellung fehl.
InvalidValueForElement	Wenn der im Element <Algorithm> angegebene Wert kein unterstützter Wert ist, schlägt die Bereitstellung fehl.
MissingConfigurationElement	Dieser Fehler tritt auf, wenn das Element <PrivateKey> nicht mit RSA Family-Algorithmen oder das Element <SecretKey> nicht mit HS Family-Algorithmen verwendet wird.
InvalidKeyConfiguration	Wenn das untergeordnete Element <Value> nicht in den Elementen <PrivateKey> oder <SecretKey> definiert ist, schlägt die Bereitstellung fehl.
EmptyElementForKeyConfiguration	Wenn das "ref"-Attribut des untergeordneten Elements <Value> der Elemente <PrivateKey> oder <SecretKey> leer oder nicht angegeben sind, schlägt die Bereitstellung fehl.
InvalidVariableNameForSecret	Dieser Fehler tritt auf, wenn der Ablaufvariablenname, der im Attribut "ref" im untergeordneten Element <Value> der <PrivateKey> oder <SecretKey>-Elemente angegeben ist, nicht das private Präfix ((private.)) enthält.
InvalidSecretInConfig	Dieser Fehler tritt auf, wenn das untergeordnete Element <Value> der <PrivateKey>- oder <SecretKey>-Elemente nicht das private Präfix (private.) enthält.
InvalidTimeFormat	Wenn der im Element <NotBefore> angegebene Wert kein unterstütztes Format verwendet, schlägt die Bereitstellung fehl.

Fehlervariablen

Diese Variablen werden bei Laufzeitfehlern festgelegt. Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen.

Variablen	Wo	Beispiel
fault.name="fault_name"	fault_name ist der Name des Fehlers, der in der obigen Tabelle Laufzeitfehler aufgeführt ist. Der Fehlername ist der letzte Teil des Fehlercodes.	fault.name Matches "InvalidToken"
JWT.failed	Bei allen JWT-Richtlinien wird im Fall eines Fehlers dieselbe Variable festgelegt.	JWT.failed = true

Beispiel für eine Fehlerantwort

Bei der Fehlerbehandlung besteht die Best Practice darin, den errorcode-Teil der Fehlerantwort zu beachten. Verlassen Sie sich nicht auf den Text in faultstring. Er kann sich ändern.

Beispiel für eine Fehlerregel

    <FaultRules>
        <FaultRule name="JWT Policy Errors">
            <Step>
                <Name>JavaScript-1</Name>
                <Condition>(fault.name Matches "InvalidToken")</Condition>
            </Step>
            <Condition>JWT.failed=true</Condition>
        </FaultRule>
    </FaultRules>