Freigeben über


Validate JWT (JWT überprüfen)

GILT FÜR: Alle API Management-Ebenen

Die validate-jwt Richtlinie erzwingt das Vorhandensein und die Gültigkeit eines unterstützten JSON-Webtokens (JWT), das von einem Identitätsanbieter bereitgestellt wurde. Das JWT kann aus einem angegebenen HTTP-Header oder aus einem angegebenen Abfrageparameter extrahiert oder von einem bestimmten Wert abgeleitet werden.

Hinweis

Verwenden Sie die richtlinie validate-azure-ad-token, um ein JWT zu überprüfen, das von Microsoft Entra bereitgestellt wurde.

Hinweis

Legen Sie die Elemente und untergeordneten Elemente einer Richtlinie in der Reihenfolge fest, die in der Richtlinienanweisung angegeben ist. Das Portal unterstützt Sie bei der Konfiguration dieser Richtlinie durch einen formularbasierten, angeleiteten Editor. Erfahren Sie mehr darüber, wie Sie API Management-Richtlinien festlegen oder bearbeiten.

Richtlinienanweisung

<validate-jwt
    header-name="name of HTTP header containing the token (alternatively, use query-parameter-name or token-value attribute to specify token)"
    query-parameter-name="name of query parameter used to pass the token (alternative, use header-name or token-value attribute to specify token)"
    token-value="expression returning the token as a string (alternatively, use header-name or query-parameter attribute to specify token)"
    failed-validation-httpcode="HTTP status code to return on failure"
    failed-validation-error-message="error message to return on failure"
    require-expiration-time="true | false"
    require-scheme="scheme"
    require-signed-tokens="true | false"
    clock-skew="allowed clock skew in seconds"
    output-token-variable-name="name of a variable to receive a JWT object representing successfully validated token">
  <openid-config url="full URL of the configuration endpoint, for example, https://login.constoso.com/openid-configuration" validate-connectivity="true | false"/>
  <issuer-signing-keys>
    <key id="kid-claim" certificate-id="mycertificate" n="modulus" e="exponent">Base64 encoded signing key</key>
    <!-- if there are multiple keys, then add additional key elements -->
  </issuer-signing-keys>
  <decryption-keys>
    <key certificate-id="mycertificate">Base64 encoded signing key</key>
    <!-- if there are multiple keys, then add additional key elements -->
  </decryption-keys>
  <audiences>
    <audience>audience string</audience>
    <!-- if there are multiple possible audiences, then add additional audience elements -->
  </audiences>
  <issuers>
    <issuer>issuer string</issuer>
    <!-- if there are multiple possible issuers, then add additional issuer elements -->
  </issuers>
  <required-claims>
    <claim name="name of the claim as it appears in the token" match="all | any" separator="separator character in a multi-valued claim">
      <value>claim value as it is expected to appear in the token</value>
      <!-- if there is more than one allowed value, then add additional value elements -->
    </claim>
    <!-- if there are multiple possible allowed claim, then add additional claim elements -->
  </required-claims>
</validate-jwt>

Attribute

Attribut BESCHREIBUNG Erforderlich Standard
Headername Der Name des HTTP-Headers, der das Token enthält. Richtlinienausdrücke sind zulässig. Einer von header-name, query-parameter-name oder token-value muss angegeben werden.
Abfrageparametername Der Name des Abfrageparameters, der das Token enthält. Richtlinienausdrücke sind zulässig. Einer von header-name, query-parameter-name oder token-value muss angegeben werden.
Tokenwert Ausdruck, der eine Zeichenfolge mit Token zurückgibt. Sie dürfen nicht als Teil des Tokenwerts zurückgeben Bearer . Richtlinienausdrücke sind zulässig. Einer von header-name, query-parameter-name oder token-value muss angegeben werden.
failed-validation-httpcode Der HTTP-Statuscode, der zurückgegeben werden soll, wenn das JWT die Überprüfung nicht besteht. Richtlinienausdrücke sind zulässig. Nein 401
failed-validation-error-message Die Fehlermeldung, die im HTTP-Antworttext zurückgegeben werden soll, wenn das JWT die Überprüfung nicht besteht. In dieser Meldung müssen alle Sonderzeichen ordnungsgemäß mit Escapezeichen versehen sein. Richtlinienausdrücke sind zulässig. Nein Die Standardfehlermeldung hängt vom Überprüfungsproblem ab, z.B. „JWT nicht vorhanden“.
require-expiration-time Boolesch. Gibt an, ob ein Ablaufanspruch im Token erforderlich ist. Richtlinienausdrücke sind zulässig. Nein Wahr
require-scheme Der Name des Tokenschemas, z. B. „Bearer“. Wenn dieses Attribut festgelegt ist, stellt die Richtlinie sicher, das das angegebene Schema im Wert für den Autorisierungsheader vorhanden ist. Richtlinienausdrücke sind zulässig. Nein
require-signed-tokens Boolesch. Gibt an, ob ein Token signiert sein muss. Richtlinienausdrücke sind zulässig. Nein Wahr
Uhr-Schiefe Zeitspanne. Verwenden Sie diese Option, um die maximal erwartete Zeitdifferenz zwischen den Systemuhren des Tokenausstellers und der API Management-Instanz anzugeben. Richtlinienausdrücke sind zulässig. Nein 0 Sekunden
output-token-variable-name Eine Zeichenfolge. Name der Kontextvariable, die tokenwert als Objekt vom Typ Jwt bei erfolgreicher Tokenüberprüfung empfängt. Richtlinienausdrücke sind nicht zulässig. Nein

Elemente

Element BESCHREIBUNG Erforderlich
openid-config Fügen Sie ein oder mehrere dieser Elemente hinzu, um einen kompatiblen OpenID-Konfigurationsendpunkt (url Attribut) anzugeben, aus dem Signaturschlüssel und Aussteller abgerufen werden können.

Legen Sie validate-connectivity optional das Attribut so fest, dass false die Überprüfung der Endpunktverfügbarkeit deaktiviert wird, wenn die URL nicht über öffentliches DNS aufgelöst werden kann.

Die Konfiguration einschließlich des JWKS (JSON Web Key-Satz) wird stündlich vom Endpunkt abgerufen und zwischengespeichert. Wenn das überprüfte Token auf einen Überprüfungsschlüssel (unter Verwendung kid des Anspruchs) verweist, der in der zwischengespeicherten Konfiguration fehlt, oder wenn der Abruf fehlschlägt, ruft die API-Verwaltung höchstens einmal pro 5 Min. vom Endpunkt ab. Diese Intervalle können ohne vorherige Ankündigung geändert werden.

Die Antwort sollte den Spezifikationen entsprechen, die unter URL definiert sind: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.

Verwenden Sie für Microsoft Entra ID den OpenID Connect metadatenendpunkt in Ihrer App-Registrierung konfiguriert, z. B.:
- v2 https://login.microsoftonline.com/{tenant-name}/v2.0/.well-known/openid-configuration
- v2 Multimandanten https://login.microsoftonline.com/organizations/v2.0/.well-known/openid-configuration
- v1 https://login.microsoftonline.com/{tenant-name}/.well-known/openid-configuration
- Kundenmandant (Vorschau) https://{tenant-name}.ciamlogin.com/{tenant-id}/v2.0/.well-known/openid-configuration

Ersetzen Des Verzeichnismandantennamens oder der ID, z. B contoso.onmicrosoft.com. für {tenant-name}.
Nein
Ausstellersignaturschlüssel Eine Liste der base64-codierten Sicherheitsschlüssel in key Unterelementen, die zum Überprüfen signierter Token verwendet werden. Wenn mehrere Sicherheitsschlüssel vorhanden sind, wird jeder Schlüssel ausprobiert, bis entweder alle verbraucht sind (in diesem Fall gibt es einen Validierungsfehler) oder ein Schlüssel erfolgreich ist (hilfreich für ein Tokenrollover).

Geben Sie optional einen Schlüssel an, indem Sie das id Attribut verwenden, um dem Anspruch des kid Tokens zu entsprechen. Um ein token zu überprüfen, das mit einem asymmetrischen Schlüssel signiert ist, geben Sie optional den öffentlichen Schlüssel mithilfe eines certificate-id Attributs an, das auf den Bezeichner eines zertifikatsuploaded in API Management hochgeladen wurde, oder das RSA-Modulus n - und exponent-Paar e des Signaturschlüssels im Base64url-codierten Format.
Nein
Entschlüsselungsschlüssel Eine Liste der Base64-codierten Schlüssel in key Unterelementen, die zum Entschlüsseln der Token verwendet werden. Wenn mehrere Sicherheitsschlüssel vorhanden sind, wird jeder Schlüssel ausprobiert, bis entweder alle verbraucht sind (in diesem Fall gibt es einen Validierungsfehler) oder ein Schlüssel erfolgreich ist.

Um ein token zu entschlüsseln, das mit einem asymmetrischen Schlüssel verschlüsselt ist, geben Sie optional den öffentlichen Schlüssel mithilfe eines certificate-id Attributs an, bei dem der Wert auf den Bezeichner eines Zertifikats festgelegt ist, das in die API-Verwaltung hochgeladen wurde.
Nein
Leserkreis Eine Liste der zulässigen Zielgruppenansprüche in audience Unterelementen, die im Token vorhanden sein können. Wenn mehrere audience-Werte vorhanden sind, wird jeder Wert ausprobiert, bis entweder alle verbraucht sind (in diesem Fall gibt es einen Überprüfungsfehler) oder ein Wert erfolgreich ist. Mindestens ein audience-Wert muss angegeben werden. Nein
Aussteller Eine Liste zulässiger Prinzipale in issuer Unterelementen, die das Token ausgestellt haben. Wenn mehrere issuer-Werte vorhanden sind, wird jeder Wert ausprobiert, bis entweder alle verbraucht sind (in diesem Fall gibt es einen Überprüfungsfehler) oder ein Wert erfolgreich ist. Nein
Erforderliche Ansprüche Eine Liste der Ansprüche in claim Unterelementen, die für das Token als gültig angesehen werden sollen. Wenn mehrere Ansprüche vorhanden sind, muss das Token Anspruchswerte entsprechend dem Wert des match Attributs abgleichen. Nein

Schlüsselattribute

Attribut BESCHREIBUNG Erforderlich Standard
id (Nur Ausstellersignaturschlüssel) Zeichenfolge. Bezeichner, der zum Abgleichen des anspruchs kid verwendet wird, der in JWT dargestellt wird. Wenn keine Schlüssel mit dem Anspruch übereinstimmen, probiert API Management alle angegebenen Schlüssel durch. Erfahren Sie mehr über den kid Anspruch in RFC. Nein
Zertifikat-ID Bezeichner einer Zertifikatentität, die in die API-Verwaltung hochgeladen wurde , verwendet, um den öffentlichen Schlüssel anzugeben, um ein token zu überprüfen, das mit einem asymmetrischen Schlüssel signiert ist. Nein
n (Nur Ausstellersignaturschlüssel) Modulus des öffentlichen Schlüssels, der verwendet wird, um den Aussteller eines Tokens zu überprüfen, das mit einem asymmetrischen Schlüssel signiert ist. Muss mit dem Wert des Exponenten eangegeben werden. Richtlinienausdrücke sind nicht zulässig. Nein
e (Nur Ausstellersignaturschlüssel) Exponent des öffentlichen Schlüssels, der verwendet wird, um den Aussteller eines Tokens zu überprüfen, das mit einem asymmetrischen Schlüssel signiert ist. Muss mit dem Wert des Moduls nangegeben werden. Richtlinienausdrücke sind nicht zulässig. Nein

Anspruchsattribute

Attribut BESCHREIBUNG Erforderlich Standard
Streichholz Das match Attribut für das claim Element gibt an, ob jeder Anspruchswert in der Richtlinie im Token vorhanden sein muss, damit die Überprüfung erfolgreich ist. Mögliche Werte:

- all - Jeder Anspruchswert in der Richtlinie muss im Token vorhanden sein, damit die Überprüfung erfolgreich ist.

- any – Mindestens ein Anspruchswert muss im Token vorhanden sein, damit die Überprüfung erfolgreich ist.
Nein alle
Trennzeichen Eine Zeichenfolge. Gibt ein Trennzeichen (z. B. „,“) zum Extrahieren eines Satzes von Werten aus einem mehrwertigen Anspruch an. Nein

Verwendung

Hinweise zur Verwendung

  • Die validate-jwt Richtlinie erfordert, dass der exp registrierte Anspruch im JWT enthalten ist, es sei denn require-expiration-time , attribut ist angegeben und auf festgelegt false.
  • Die Richtlinie unterstützt symmetrische und asymmetrische Signaturalgorithmen:
    • Symmetrisch – Die folgenden Verschlüsselungsalgorithmen werden unterstützt: A128CBC-HS256, A192CBC-HS384, A256CBC-HS512.
      • Wenn er in der Richtlinie verwendet wird, muss der Schlüssel inline innerhalb der Richtlinie in Base64-codiertem Format angegeben werden.
    • Asymmetrisch – Die folgenden Verschlüsselungsalgorithmen werden unterstützt: PS256, RS256, RS512, ES256.
      • Wenn er in der Richtlinie verwendet wird, kann der Schlüssel entweder über einen Open ID-Konfigurationsendpunkt oder durch Angabe der ID eines hochgeladenen Zertifikats (im PFX-Format) bereitgestellt werden, das den öffentlichen Schlüssel oder das Modulus-Exponent-Paar des öffentlichen Schlüssels enthält.
  • Wenn die API-Verwaltungsinstanz in ein virtuelles Netzwerk eingefügt oder in ein virtuelles Netzwerk integriert ist und openid-config Endpunkt-URLs in der Richtlinie konfiguriert sind, legen Sie das validate-connectivity Attribut fest, um die Überprüfung der Endpunktverfügbarkeit zu false deaktivieren.
  • Sie können Richtlinien für die Zugriffsbeschränkung in verschiedenen Bereichen zu unterschiedlichen Zwecken verwenden. Sie können beispielsweise die gesamte API mit Microsoft Entra Authentifizierung sichern, indem Sie die richtlinie validate-jwt auf API-Ebene anwenden oder sie auf API-Vorgangsebene anwenden und claims für eine genauere Kontrolle verwenden.
  • Bei Verwendung eines benutzerdefinierten Headers (header-name) wird das konfigurierte erforderliche Schema (require-scheme) ignoriert. Um ein erforderliches Schema zu verwenden, müssen JWTs im Authorization Header angegeben werden.

Beispiele

Einfache Tokenüberprüfung

<validate-jwt header-name="Authorization" require-scheme="Bearer">
    <issuer-signing-keys>
        <key>{{jwt-signing-key}}</key>  <!-- signing key specified as a named value -->
    </issuer-signing-keys>
    <audiences>
        <audience>@(context.Request.OriginalUrl.Host)</audience>  <!-- audience is set to API Management host name -->
    </audiences>
    <issuers>
        <issuer>http://contoso.com/</issuer>
    </issuers>
</validate-jwt>

Tokenvalidierung mit RSA-Zertifikat

<validate-jwt header-name="Authorization" require-scheme="Bearer">
    <issuer-signing-keys>
        <key certificate-id="my-rsa-cert" />  <!-- signing key specified as certificate ID, enclosed in double-quotes -->
    </issuer-signing-keys>
    <audiences>
        <audience>@(context.Request.OriginalUrl.Host)</audience>  <!-- audience is set to API Management host name -->
    </audiences>
    <issuers>
        <issuer>http://contoso.com/</issuer>
    </issuers>
</validate-jwt>

Microsoft Entra ID Überprüfung des Einzelnen Mandantentokens

<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
    <openid-config url="https://login.microsoftonline.com/contoso.onmicrosoft.com/.well-known/openid-configuration" />
    <audiences>
        <audience>00001111-aaaa-2222-bbbb-3333cccc4444</audience>
    </audiences>
    <required-claims>
        <claim name="id" match="all">
            <value>insert claim here</value>
        </claim>
    </required-claims>
</validate-jwt>

Microsoft Entra ID Überprüfung des Kundenmandantentokens

<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
	<openid-config url="https://<tenant-name>.ciamlogin.com/<tenant-id>/v2.0/.well-known/openid-configuration" />
	<required-claims>
		<claim name="azp" match="all">
			<value>insert claim here</value>
		</claim>
	</required-claims>
</validate-jwt>

Azure Active Directory B2C-Tokenüberprüfung

<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
    <openid-config url="https://login.microsoftonline.com/tfp/contoso.onmicrosoft.com/b2c_1_signin/v2.0/.well-known/openid-configuration" />
    <audiences>
        <audience>11112222-bbbb-3333-cccc-4444dddd5555</audience>
    </audiences>
    <required-claims>
        <claim name="id" match="all">
            <value>insert claim here</value>
        </claim>
    </required-claims>
</validate-jwt>

Von Bedeutung

Ab dem 1. Mai 2025 steht Azure AD B2C nicht mehr zum Kauf für neue Kunden zur Verfügung. Weitere Informationen finden Sie in unseren HÄUFIG gestellten Fragen.

Tokenüberprüfung mithilfe eines Entschlüsselungsschlüssels

In diesem Beispiel wird gezeigt, wie Sie mithilfe der validate-jwt Richtlinie ein Token überprüfen, das mit einem Entschlüsselungsschlüssel entschlüsselt wird. Der Schlüssel wird mithilfe der ID eines hochgeladenen Zertifikats (im PFX-Format) angegeben, das den öffentlichen Schlüssel enthält.

<validate-jwt header-name="Authorization" require-scheme="Bearer" output-token-variable-name="jwt">
    <issuer-signing-keys>
        <key>{{jwt-signing-key}}</key> <!-- signing key is stored in a named value -->
    </issuer-signing-keys>
    <audiences>
        <audience>@(context.Request.OriginalUrl.Host)</audience>
    </audiences>
    <issuers>
        <issuer>contoso.com</issuer>
    </issuers>
    <required-claims>
        <claim name="group" match="any">
            <value>finance</value>
            <value>logistics</value>
        </claim>
    </required-claims>
    <decryption-keys>
        <key certificate-id="my-certificate-in-api-management" /> <!-- decryption key specified as certificate ID -->
    </decryption-keys>
</validate-jwt>

Autorisieren des Zugriffs auf Vorgänge basierend auf Tokenansprüchen

In diesem Beispiel wird gezeigt, wie validate-jwt Die Richtlinie verwendet wird, um den Zugriff auf Vorgänge basierend auf dem Tokenanspruchswert zu autorisieren.

<validate-jwt header-name="Authorization" require-scheme="Bearer" output-token-variable-name="jwt">
    <issuer-signing-keys>
        <key>{{jwt-signing-key}}</key> <!-- signing key is stored in a named value -->
    </issuer-signing-keys>
    <audiences>
        <audience>@(context.Request.OriginalUrl.Host)</audience>
    </audiences>
    <issuers>
        <issuer>contoso.com</issuer>
    </issuers>
    <required-claims>
        <claim name="group" match="any">
            <value>finance</value>
            <value>logistics</value>
        </claim>
    </required-claims>
</validate-jwt>
<choose>
    <when condition="@(context.Request.Method == "POST" && !((Jwt)context.Variables["jwt"]).Claims["group"].Contains("finance"))">
        <return-response>
            <set-status code="403" reason="Forbidden" />
        </return-response>
    </when>
</choose>

Weitere Informationen zum Arbeiten mit Richtlinien finden Sie hier: