Token zum Hinzufügen von Authentifizierung und Autorisierung zu API-Deployments validieren

Bevor Sie die Authentifizierung und Autorisierung für API-Deployments mithilfe von JWTs aktivieren können, müssen Sie Folgendes beachten:

• Ein OAuth2-konformer Identitätsprovider (z.B. OCI IAM mit Identitätsdomains, Oracle Identity Cloud Service (IDCS), Auth0) muss bereits für die Ausstellung von JWTs für Benutzer eingerichtet worden sein, die auf das API-Deployment zugreifen können.
• Wenn Sie benutzerdefinierte Claims in Autorisierungs-Policys verwenden möchten, muss der Identitätsprovider so eingerichtet werden, dass er den ausgestellten JWTs die benutzerdefinierten Claims hinzufügt.

Weitere Informationen finden Sie in der Dokumentation des Identitätsproviders (z.B. Dokumentation zu OCI IAM mit Identitätsdomains, Dokumentation zu Oracle Identity Cloud Service (IDCS) oder Dokumentation zu Auth0).

So validieren Sie ein JWT mit einem entsprechenden öffentlichen Prüfschlüssel, der vom ausstellenden Identitätsprovider bereitgestellt wird:

• Als Signaturalgorithmus zur Generierung der JWT-Signatur muss RS256, RS384 oder RS512 verwendet werden.
• Der öffentliche Prüfschlüssel muss mindestens 2048 Bit lang sein und darf 4096 Bit nicht überschreiten.

So validieren Sie Token mit dem Introspektionsendpunkt eines Autorisierungsservers:

• Sie müssen bereits eine Clientanwendung beim Autorisierungsserver erstellt und registriert haben, um die Clientzugangsdaten (eine Client-ID und ein Client Secret) abzurufen. Weitere Informationen finden Sie in der Dokumentation des Autorisierungsservers (z.B. Dokumentation zu OCI IAM mit Identitätsdomains, Dokumentation zu Oracle Identity Cloud Service (IDCS) oder Dokumentation zu Auth0).
• Sie müssen das Client Secret, das Sie vom Autorisierungsserver erhalten haben, bereits als Secret in einem Vault im Vault-Service gespeichert haben (siehe Secret in einem Vault erstellen). Außerdem müssen Sie die OCID und die Versionsnummer des Secrets kennen.
• Sie müssen bereits eine Policy eingerichtet haben, um API-Gateways in einer dynamischen Gruppe die Berechtigung für den Zugriff auf das Vault Secret mit dem Client Secret zu erteilen (siehe Policy erstellen, um API-Gateways Zugriff auf Zugangsdaten zu erteilen, die als Secrets im Vault-Service gespeichert sind).

So fügen Sie mit der Konsole Authentifizierungsanforderungs-Policys und Autorisierungsanforderungs-Policys zu einer API-Deployment-Spezifikation hinzu:

1. Erstellen oder aktualisieren Sie ein API-Deployment mit der Konsole, wählen Sie die Option Völlig neu aus, und geben Sie auf der Seite Basisinformationen Details ein.

   Weitere Informationen finden Sie unter API durch das Erstellen eines API-Deployment in einem API-Gateway bereitstellen und API-Gateway aktualisieren.

2. Wählen Sie Weiter aus, um die Seite Authentifizierung anzuzeigen.

3. Wählen Sie Einzelne Authentifizierung aus, um anzugeben, dass Sie einen einzelnen Authentifizierungsserver für alle Anforderungen verwenden möchten.

   Bei diesen Anweisungen wird davon ausgegangen, dass Sie einen einzelnen Authentifizierungsserver verwenden möchten. Wenn Sie alternativ mehrere Authentifizierungsserver verwenden möchten, wählen Sie Multi-Authentifizierung aus, und befolgen Sie die Anweisungen unter Mehrere Authentifizierungsserver mit der Konsole demselben API-Deployment hinzufügen.

4. Aktivieren oder deaktivieren Sie das Kontrollkästchen Anonymen Zugriff aktivieren:, um anzugeben, ob nicht authentifizierte (d.h. anonyme) Endbenutzer auf Routen im API-Deployment zugreifen können.

   Standardmäßig ist diese Option nicht ausgewählt. Wenn Sie den Zugriff anonymer Benutzer auf Routen nie zulassen möchten, wählen Sie diese Option nicht aus. Hinweis: Wenn Sie diese Option auswählen, müssen Sie auch explizit jede Route angeben, auf die anonym zugegriffen werden kann. Wählen Sie dazu in der Autorisierungs-Policy jeder einzelnen Route Anonym als Autorisierungstyp aus.

5. Wählen Sie in der Optionsliste Authentifizierungstyp die Option OAuth 2.0 / OpenID Connect, und geben Sie Folgendes an:
   • Tokenverzeichnis: Gibt an, ob Token in einem Anforderungsheader oder einem Abfrageparameter enthalten sind.

   • Authentifizierungstokendetails: Geben Sie je nachdem, ob Token in einem Anforderungsheader oder einem Abfrageparameter enthalten sind, Folgendes an:

     • Tokenheadername: und Authentifizierungsschema: Wenn Token in einem Anforderungsheader enthalten sind, geben Sie den Namen des Headers (Beispiel: Authorization) und das HTTP-Authentifizierungsschema ein (derzeit wird derzeit nur Bearer unterstützt).
     • Tokenparametername: Wenn Token in einem Abfrageparameter enthalten sind, geben Sie den Namen des Abfrageparameters ein.
6. Geben Sie an, wie das API Gateway Token validieren soll:

   1. Wenn das API-Gateway sowohl JWT-Token als auch Nicht-JWT-Token mit dem Introspektionsendpunkt eines OAuth 2.0-Autorisierungsservers mit Clientzugangsdaten (einschließlich eines Client Secrets, das von einem Vault im Vault-Service abgerufen wird) validieren soll, wählen Sie in der Liste Typ die Option OAuth 2.0 Introspektionsendpunkt aus, und geben Sie Folgendes an:

      • Client-ID: Die Client-ID, die an den Introspektionsendpunkt gesendet werden soll. Sie erhalten eine Client-ID, indem Sie eine Client-Anwendung beim Autorisierungsserver erstellen und registrieren. Beispiel: 5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1 . Siehe Voraussetzungen für die Tokenauthentifizierung.
      • Vault in <compartment-name>: Der Name eines Vaults im Vault-Service, der das Client Secret enthält, das an den Introspektionsendpunkt gesendet werden soll. Sie erhalten ein Client Secret, indem Sie eine Clientanwendung beim Autorisierungsserver erstellen und registrieren. Siehe Voraussetzungen für die Tokenauthentifizierung.
      • Vault Secret in <compartment name>: Der Name eines Vault Secrets mit dem Client Secret, das an den Introspektionsendpunkt gesendet werden soll.
      • Vault Secret-Versionsnummer: Die Version des Vault Secrets mit dem Client Secret, das an den Introspektionsendpunkt gesendet werden soll.
      • Discovery-URL: Die bekannte URL des Autorisierungsservers, von dem das API-Gateway Autorisierungsmetadatenendpunkte abrufen soll. Beispiel: https://my-idp/oauth2/default/.well-known/openid-configuration.

        Beachten Sie, dass die URL aus dem Subnetz mit dem API-Gateway geroutet werden kann, in dem die API bereitgestellt wird.

      • Maximale Cachedauer in Stunden: Die Anzahl der Stunden (zwischen 1 und 24), die das API-Gateway die Antwort vom Introspektionsendpunkt cachen soll.
      • Max. Clock Skew in Sekunden: (Optional) Der maximale Zeitunterschied zwischen den Systemuhren des Autorisierungsservers, der ein Token abgesetzt hat, und dem API-Gateway. Der hier eingegebene Wert wird berücksichtigt, wenn das API-Gateway ein JWT validiert, um zu bestimmen, ob es noch gültig ist. Verwenden Sie dazu den Claim nicht vor (nbf, falls vorhanden) und den Ablaufclaim (exp) im JWT. Der Mindestwert (und Standardwert) ist 0, der Höchstwert ist 120.
      • SSL-Prüfung deaktivieren: Gibt an, ob die SSL-Prüfung bei der Kommunikation mit dem Autorisierungsserver deaktiviert werden soll. Standardmäßig ist diese Option nicht ausgewählt. Oracle empfiehlt, diese Option nicht auszuwählen, weil sie die Tokenvalidierung kompromittieren kann. API Gateway vertraut den Zertifikaten von mehreren Certificate Authoritys, die für OCI IAM mit Identitätsdomains, Oracle Identity Cloud Service (IDCS), Auth0 und Okta ausgestellt werden.

   2. Wenn das API-Gateway JWTs durch das Abrufen öffentlicher Prüfschlüssel vom Identitätsprovider zur Laufzeit validieren soll, wählen Sie in der Liste Typ den Eintrag Remote-JWKS aus, und geben Sie Folgendes an:

      • JWKS-URI: Die URI, von der das JSON Web Key Set (JWKS) abgerufen werden soll, mit dem die Signatur der JWTs verifiziert werden soll. Beispiel: https://www.somejwksprovider.com/oauth2/v3/certs. Weitere Informationen über die anzugebende URI finden Sie unter Identitätsproviderdetails für iss- und aud-Claims sowie für die JWKS-URI.

        Beachten Sie dabei Folgendes:

        • Die URI muss aus dem Subnetz mit dem API-Gateway geroutet werden können, in dem die API bereitgestellt wird.

        • Wenn das API-Gateway das JWKS nicht abrufen kann, geben alle Anforderungen an das API-Deployment einen HTTP 500-Antwortcode zurück. Weitere Informationen zum Fehler finden Sie im Ausführungslog des API-Gateways (siehe Logging zu API-Deployments hinzufügen).
        • Bestimmte Schlüsselparameter müssen im JWKS vorhanden sein, um die JWT-Signatur zu verifizieren (siehe Erforderliche Schlüsselparameter zum Überprüfen von JWT-Signaturen).
        • Das JWKS kann bis zu zehn Schlüssel enthalten.
      • Maximale Cachedauer in Stunden: Die Anzahl der Stunden (zwischen 1 und 24), die das API-Gateway das JWKS nach dem Abrufen cachen soll.
      • SSL-Verifizierung deaktivieren: Gibt an, ob die SSL-Verifizierung bei der Kommunikation mit dem Identitätsprovider deaktiviert werden soll. Standardmäßig ist diese Option nicht ausgewählt. Oracle empfiehlt, diese Option nicht auszuwählen, weil sie die JWT-Validierung kompromittieren kann. API Gateway vertraut den Zertifikaten von mehreren Certificate Authoritys, die für OCI IAM mit Identitätsdomains, Oracle Identity Cloud Service (IDCS), Auth0 und Okta ausgestellt werden.

   3. Wenn das API-Gateway JWTs mit öffentlichen Prüfschlüsseln validieren soll, die bereits von einem Identitätsprovider ausgestellt wurden (damit das API-Gateway JWTs lokal prüfen kann, ohne den Identitätsprovider kontaktieren zu müssen), wählen Sie in der Liste Typ den Eintrag Statische Schlüssel aus, und geben Sie bis zu zehn statische Schlüssel an:

      • Schlüssel-ID: Die ID des statischen Schlüssels, mit dem das JWT signiert wird. Der Wert muss mit dem kid-Claim im JWT-Header übereinstimmen. Beispiel: master_key.

      • Schlüsselformat: Das Format des statischen Schlüssels entweder als JSON Web Key oder als PEM-codierter Public Key.

        • JSON Web Key: Wenn es sich bei dem statischen Schlüssel um einen JSON Web Key handelt, fügen Sie den Schlüssel in dieses Feld ein.

          Beispiel:

          {
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
          

          Beachten Sie, dass bestimmte Parameter im statischen Schlüssel vorhanden sein müssen, um die JWT-Signatur zu verifizieren (siehe Erforderliche Schlüsselparameter zum Überprüfen von JWT-Signaturen). Beachten Sie auch, dass RSA derzeit der einzige unterstützte Schlüsseltyp (kty) ist.

        • PEM-verschlüsselter Public Key: Wenn es sich bei dem statischen Schlüssel um einen PEM-verschlüsselten Public Key handelt, fügen Sie den Schlüssel in dieses Feld ein. Beispiel:

          -----BEGIN PUBLIC KEY-----
          XsEiCeYgglwW/KAhSSNRVdD60QlXYMWHOhXzSFDZCLf1WXxKMZCiMvVrsBIzmFEXnFmcsO2mxwlL5/8qQudomoP+yycJ2gWPIgqsZcQRheJWxVC5ep0MeEHlvLnEvCi9utpAnjrsZCQ7plfZVPX7XORvezwqQhBfYzwA27M2FgOOs8DOIYfqQ1Ki3DMqEppFnjLcjgQtknbTlT7YgG6tzobwig8M2KIrPjJ0BmbJAFH
          -----END PUBLIC KEY-----
          

          Beachten Sie, dass die Marker -----BEGIN PUBLIC KEY----- und -----END PUBLIC KEY----- erforderlich sind.

      • Weiterer Schlüssel: Wählen Sie diese Option aus, um weitere Schlüssel hinzuzufügen (max. zehn).
7. (Optional) Geben Sie zusätzliche Details zur JWT-Tokenvalidierung an:

   1. Geben Sie im Abschnitt Aussteller Werte an, die im Ausstellerclaim (iss) eines JWT für den Zugriff auf das API-Deployment zulässig sind:

      • Zulässige Aussteller: Geben Sie die URL (oder eine Textzeichenfolge) für einen Identitätsprovider an, die im Ausstellerclaim (iss) eines JWT für den Zugriff auf das API-Deployment zulässig ist. Beispiel: Um den Zugriff auf das API-Deployment über ein von OCI IAM mit Identitätsdomains ausgestelltes JWT zu ermöglichen, geben Sie https://identity.oraclecloud.com/ ein. Informationen hierzu finden Sie unter Identitätsproviderdetails für iss- und aud-Claims sowie für die JWKS-URI.
      • Weiterer Aussteller: Wählen Sie diese Option aus, um weitere Identitätsprovider hinzuzufügen (bis zu fünf).

   2. Geben Sie im Abschnitt Zielgruppen Werte an, die im Zielgruppenclaim (aud) eines JWT für den Zugriff auf das API-Deployment zulässig sind:

      • Zulässige Zielgruppen: Geben Sie einen Wert an, der im Zielgruppenclaim (aud) eines JWT zur Identifikation des beabsichtigten Empfängers des Tokens zulässig ist. Beispiel: Die Zielgruppe kann (muss aber nicht) dem Hostnamen des API-Gateways entsprechen. Informationen hierzu finden Sie unter Identitätsproviderdetails für iss- und aud-Claims sowie für die JWKS-URI.
      • Weitere Zielgruppe: Wählen Sie diese Option aus, um weitere Zielgruppen hinzuzufügen (max. fünf).

   3. Claims-Validierung: (Optional) Zusätzlich zu den bereits angegebenen Werten für die Zielgruppenansprüche aud und den Ausstelleransprüche iss können Sie Namen und Werte für mindestens einen zusätzlichen Claim angeben, der in einem JWT validiert werden soll. Beachten Sie, dass alle eingegebenen Schlüsselnamen und -werte einfach wie Zeichenfolgen behandelt werden und exakt mit den Namen und Werten im JWT übereinstimmen müssen. Das Abgleichen von Mustern und andere Datentypen werden nicht unterstützt.

      • Claim ist erforderlich: Geben Sie an, ob der Claim im Feld Claimschlüssel im JWT enthalten sein muss.
      • Claimschlüssel: (Optional) Geben Sie den Namen eines Claims an, der in einem JWT enthalten sein kann oder muss. Wenn der Claim im JWT enthalten sein muss, wählen Sie Erforderlich aus. Der angegebene Claimname kann ein reservierter Claimname sein, wie der Subject-Claim (sub), oder ein benutzerdefinierter Claimname, der von einem bestimmten Identitätsprovider ausgestellt wird.
      • Claimwerte: (Optional) Geben Sie einen zulässigen Wert für den Claim im Feld Claimschlüssel an. Wählen Sie das Pluszeichen (+), um einen weiteren zulässigen Wert einzugeben. Wenn Sie einen oder mehrere zulässige Werte für den Claim angeben, führt das API-Gateway die Validierung so aus, dass der Claim einen der angegebenen Werte aufweist.

      Beachten Sie, dass Sie einen Claim in einem JWT angeben können, ohne dafür einen Wert anzugeben. Geben Sie dazu den Namen des Anspruchs in das Feld Anspruchsschlüssel ein, lassen Sie das Feld Anspruchswerte leer, und legen Sie gegebenenfalls Anspruch erforderlich fest.

8. Geben Sie an, wie das API-Gateway eine nicht erfolgreiche Authentifizierungsantwort verarbeiten soll (nach einem nicht erfolgreichen Versuch, ein fehlendes oder ungültiges Token zu validieren), indem Sie eine Validierungsfehler-Policy einrichten:
   1. Wenn das API-Gateway einen HTTP 401-Statuscode und den WWW-Authenticate-Header in der Antwort (die Standardantwort auf ein fehlendes oder ungültiges Token) senden soll, wählen Sie Standard (HTTP 401 nicht autorisiert) aus.

   2. Wenn das API-Gateway einen OpenID Connect-Autorisierungsfluss verwenden soll, um ein neues JWT-Zugriffstoken abzurufen, wählen Sie OAuth 2.0 aus. Diese Option ist nur verfügbar, wenn Sie zuvor in der Liste Validierungstyp die Option OAuth 2.0 Introspektionsendpunkt ausgewählt haben. Wählen Sie eine der folgenden Optionen aus:

      • Geltungsbereiche: Mindestens ein Zugriffsbereich, der in einen scope-Claim aufgenommen werden soll, der an den Autorisierungsserver gesendet wird. Um den OpenID Connect-Autorisierungsablauf zu verwenden, müssen Sie openid als einen der Geltungsbereiche aufnehmen. Beispiel: openid, email:read, profile.
      • Antworttyp: Der Typ der im Autorisierungsablauf erforderlichen Antwort. Geben Sie code als Antworttyp ein.
      • Fallback-Umleitungspfad: (optional) Ein relativer Pfad im aktuellen API-Deployment, an den API-Clients umgeleitet werden sollen, wenn die ursprüngliche Anforderung eine PUT-Anforderung oder eine POST-Anforderung war. Beispiel: /home

        Wenn die ursprüngliche Anforderung eine GET-Anforderung war, wird die Anforderungsverarbeitung mit einem neuen JWT-Zugriffstoken fortgesetzt, sodass kein Fallback-Pfad verwendet wird.

      • Abmeldepfad: (optional) Ein relativer Pfad zu einem Abmelde-Backend im aktuellen API-Deployment. Der angegebene Pfad muss mit dem für das Abmelde-Backend definierten Routenpfad übereinstimmen. Beispiel: /revoke

        Ein API-Client kann das Backend für die Abmeldung aufrufen, um Token zu entziehen. Ein Aufruf des Abmelde-Backends kann eine URL nach der Abmeldung als Abfrageparameter mit dem Namen postLogoutUrl enthalten. Siehe Abmeldung als API-Gateway-Backend hinzufügen.

      • Antwortablauf in Stunden: (optional) Die Zeitspanne, in der das vom Autorisierungsablauf generierte JWT-Token gecacht wird. Der Standardwert beträgt 1 Stunde.
      • Clientzugangsdaten des Introspektionsendpunkts OAuth2 verwenden: Geben Sie an, ob dieselben Clientdetails verwendet werden sollen, die Sie zuvor für den OAuth 2.0-Introspektionsendpunkt angegeben haben, um ein neues JWT-Zugriffstoken abzurufen (in der Regel der Fall). Wenn Sie die zuvor angegebenen Details nicht verwenden möchten, geben Sie wie folgt andere Clientdetails ein, um ein neues JWT-Zugriffstoken vom Autorisierungsserver abzurufen:
        • Client-ID: Die Client-ID, die an den Introspektionsendpunkt gesendet werden soll. Beispiel: 5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1
        • Vault in <compartment-name>: Der Name eines Vaults im Vault-Service, der das Client Secret enthält, das an den Introspektionsendpunkt gesendet werden soll.
        • Vault Secret in <compartment name>: Der Name des Vault Secrets mit dem Client Secret, das an den Introspektionsendpunkt gesendet werden soll.
        • Vault Secret-Versionsnummer: Die Version des Vault Secrets mit dem Client Secret, das an den Introspektionsendpunkt gesendet werden soll.

      Sie können optional die Token und Werte, die während der OpenID-Autorisierungsabläufe abgerufen werden, in Cookies speichern, indem Sie Erweiterte Optionen anzeigen auswählen und Folgendes auswählen:

      • Cookies für Session verwenden: (Optional) Geben Sie an, wie neu generierte JWT-Token als nicht menschenlesbare Zeichenfolgen am Ende eines OpenID Connect-Autorisierungsablaufs gespeichert werden:
        • Wählen Sie diese Option, wenn Sie das neue JWT-Token in einem Sessioncookie speichern möchten. Um potenzielle CSRF-Angriffe zu verhindern, gibt das API-Gateway, wenn es das Token in einem Sessioncookie speichert, auch ein CSRF-Token in einem X-CSRF-TOKEN-Antwortheader zurück. Nachfolgende Anforderungen an das API-Gateway (außer GET-Anforderungen) müssen das CSRF-Token zusätzlich zum JWT-Token im automatisch enthaltenen Sessioncookie in einen X-CSRF-TOKEN-Anforderungsheader aufnehmen.
        • Wählen Sie diese Option nicht aus, wenn Sie das neue JWT-Token nicht in einem Sessioncookie speichern möchten. Stattdessen gibt das API-Gateway ein nicht menschenlesbares Token in einem X-APIGW-TOKEN-Antwortheader zurück. Nachfolgende Anforderungen an das API-Gateway müssen dasselbe Token in einem X-APIGW-TOKEN-Anforderungsheader enthalten.

        Siehe Hinweise zum Schutz vor Cross-Site Request Forgery (CSRF)

      • Cookies für Zwischenschritte verwenden: (optional) Geben Sie an, wie Zwischenschrittwerte des Autorisierungsflusses gespeichert werden sollen (z.B. Anforderungsparameter). Wählen Sie diese Option aus, um die Werte in Browser-Cookies zu speichern. Deaktivieren Sie diese Option, um die Werte mit dem API-Gateway zu speichern.
      • PKCE verwenden: (optional) Geben Sie an, ob PKCE (Proof Key for Code Exchange) für zusätzliche Sicherheit verwendet werden soll. PKCE ist eine OAuth 2.0-Sicherheitserweiterung zur Verhinderung von CSRF (Cross-Site Request Forgery) und Autorisierungscode-Injection-Angriffen. PKCE ist kein Ersatz für ein Client Secret, und PKCE wird auch dann empfohlen, wenn ein Client Secret verwendet wird. Weitere Informationen zu PKCE finden Sie in der OAuth 2.0-Dokumentation.
   3. Wenn Sie die Antwort auf einen nicht erfolgreichen Versuch anpassen möchten, ein fehlendes oder ungültiges Token zu validieren, wählen Sie Benutzerdefinierte Antwort aus, und geben Sie einen Statuscode (und einen optionalen Nachrichtentext) an, der an den API-Client zurückgegeben werden soll:
      • HTTP-Statuscode: Geben Sie einen alternativen HTTP-Statuscode ein. Beispiel: 500.
      • Nachrichtentext: Geben Sie einen Nachrichtentext ein. Beispiel: Unfortunately, authentication failed.Der Nachrichtentext kann eine beliebige Kontextvariable enthalten (außer request.body).
      • Ändern Sie optional die Header der Antwort, die das API-Gateway an den API-Client zurückgibt, indem Sie eine Headertransformationsantwort-Policy angeben. Weitere Informationen zu Headertransformations-Policys finden Sie unter Headertransformationsantwort-Policys hinzufügen.

9. Wählen Sie Weiter aus, um Details zu einzelnen Routen im API-Deployment auf der Seite Routen einzugeben.

10. Geben Sie im Abschnitt Route 1 die erste Route im API-Deployment an, die einem Backend-Service einen Pfad und eine oder mehrere Methoden zuordnet:

    • Pfad: Einen Pfad zum Backend-Service für API-Aufrufe, die die aufgeführten Methoden verwenden. Beachten Sie, dass der von Ihnen angegebene Routenpfad:

      • relativ zum Deployment-Pfadpräfix ist
      • einen Schrägstrich ( / ) vorangestellt haben muss. Es kann nur ein einzelner Schrägstrich verwendet werden
      • mehrere Schrägstriche enthalten (sofern diese nicht aufeinander folgen) und mit einem Schrägstrich enden kann
      • alphanumerische Zeichen in Großbuchstaben und Kleinbuchstaben enthalten kann
      • die folgenden Sonderzeichen enthalten kann: $ - _ . + ! * ' ( ) , % ; : @ & =
      • Parameter und Platzhalter enthalten kann (siehe Pfadparameter und Platzhalter zu Routenpfaden hinzufügen)
    • Methoden: Eine oder mehrere Methoden, die vom Backend-Service akzeptiert werden (durch Komma getrennt). Beispiel: GET, PUT.

    • Ein einzelnes Backend hinzufügen oder Mehrere Backends hinzufügen: Gibt an, ob alle Anforderungen an dasselbe Backend weitergeleitet oder Anforderungen entsprechend der von Ihnen eingegebenen Kontextvariable und Regeln an verschiedene Backends weitergeleitet werden sollen.

      Bei diesen Anweisungen wird davon ausgegangen, dass Sie ein einzelnes Backend verwenden möchten. Wählen Sie daher Ein einzelnes Backend hinzufügen aus. Wenn Sie alternativ andere Backends verwenden möchten, wählen Sie Mehrere Backends hinzufügen aus, und befolgen Sie die Anweisungen unter Dynamische Backend-Auswahl mit der Konsole zu einer API-Deployment-Spezifikation hinzufügen.

    • Backend-Typ: Den Typ des Backend-Service. Wählen Sie dazu eine der folgenden Optionen:
      • HTTP: Bei einem HTTP-Backend müssen Sie auch eine URL und Timeoutdetails angeben. Außerdem müssen Sie angeben, ob die SSL-Überprüfung deaktiviert werden soll (siehe HTTP- oder HTTPS-URL als API-Gateway-Backend hinzufügen).
      • Oracle Functions: Wenn Sie ein OCI Functions-Backend verwenden, müssen Sie auch die Anwendung und Funktion angeben (siehe Funktion in OCI Functions als API-Gateway-Backend hinzufügen).
      • Standardantwort: Bei einem Standardantwort-Backend müssen Sie auch den HTTP-Statuscode, den Inhalt im Hauptteil der Antwort und mindestens ein HTTP-Headerfeld angeben (siehe Standardantworten als API-Gateway-Backend hinzufügen).
      • Abmeldung: Für ein Abmelde-Backend müssen Sie auch eine Liste der zulässigen URLs angeben, zu denen eine Anforderung umgeleitet werden kann, um Token zu entziehen, und optional Daten, die an die Abmelde-URL übergeben werden sollen (siehe Abmeldung als API-Gateway-Backend hinzufügen).

11. Um eine Autorisierungs-Policy anzugeben, die für eine einzelne Route gilt, wählen Sie Routenanforderungs-Policys einblenden und dann die Schaltfläche Hinzufügen neben Autorisierung aus, und geben Sie:

    • Autorisierungstyp: Gibt an, wie Zugriff auf die Route erteilt wird. Wählen Sie eine der folgenden Optionen aus:

      • Beliebig: Zugriff wird nur Endbenutzern erteilt, die erfolgreich authentifiziert wurden, sofern das JWT einen scope-Claim mit mindestens einem der Zugriffsgeltungsbereiche enthält, die Sie im Feld Zulässiger Geltungsbereich angegeben haben. In diesem Fall zeigt die Option Anonymen Zugriff aktivieren der Authentifizierungs-Policy keine Wirkung.
      • Anonym: Zugriff wird allen Endbenutzern erteilt, selbst wenn diese nicht erfolgreich mit dem JWT authentifiziert wurden. In diesem Fall müssen Sie die Option Anonymen Zugriff aktivieren der Authentifizierungs-Policy ausgewählt haben.
      • Nur Authentifizierung: Zugriff wird nur Endbenutzern erteilt, die erfolgreich mit dem JWT authentifiziert wurden. In diesem Fall zeigt die Option Anonymen Zugriff aktivieren der Authentifizierungs-Policy keine Wirkung.
    • Zulässiger Geltungsbereich: Wenn Sie Beliebig als Autorisierungstyp ausgewählt haben, geben Sie eine kommagetrennte Liste mit mindestens einer Zeichenfolge ein, die einem Zugriffsgeltungsbereich im JWT entspricht. Zugriff wird nur Endbenutzern erteilt, die erfolgreich authentifiziert wurden, sofern das JWT einen scope-Claim mit einem der angegebenen Zugriffsgeltungsbereiche enthält. Beispiel: read:hello
    Hinweis
    
    

    Wenn Sie keine Autorisierungs-Policy für eine bestimmte Route angeben, wird der Zugriff basierend auf der Annahme erteilt, dass eine solche Policy vorhanden ist, und der Autorisierungstyp wird auf Nur Authentifizierung gesetzt. Anders ausgedrückt: Ungeachtet der Einstellung der Option Anonymen Zugriff aktivieren der Authentifizierungs-Policy können:

    • nur authentifizierte Endbenutzer auf die Route zugreifen
    • alle authentifizierten Endbenutzer unabhängig von den Zugriffsgeltungsbereichen im scope-Claim des JWT auf die Route zugreifen
    • anonyme Endbenutzer nicht auf die Route zugreifen
12. Wählen Sie Änderungen anwenden und dann Weiter aus, um die Details zu prüfen, die Sie für das API-Deployment eingegeben haben.
13. Wählen Sie Erstellen oder Änderungen speichern aus, um das API-Deployment zu erstellen oder zu aktualisieren.
14. (Optional) Bestätigen Sie, dass die API erfolgreich bereitgestellt wurde, indem Sie sie aufrufen (siehe In einem API-Gateway bereitgestellte API aufrufen).

So fügen Sie Authentifizierungsanforderungs-Policys und Autorisierungsanforderungs-Policys zu einer API-Deployment-Spezifikation in einer JSON-Datei hinzu:

1. Bearbeiten Sie mit Ihrem bevorzugten JSON-Editor die vorhandene API-Deployment-Spezifikation, der Sie eine Authentifizierungs- und Autorisierungsfunktionalität hinzufügen möchten, oder erstellen Sie eine neue API-Deployment-Spezifikation (siehe API-Deployment-Spezifikation erstellen).

   Die API-Deployment-Spezifikation beinhaltet zumindest einen routes-Abschnitt, der Folgendes enthält:

   • Einen Pfad. Beispiel: /hello
   • Mindestens eine Methode. Beispiel: GET
   • Eine Definition eines Backends. Beispiel: Eine URL oder die OCID einer Funktion in OCI Functions.

   Beispiel: Die folgende Basisspezifikation für das API-Deployment definiert eine einfache serverlose Hello World-Funktion in OCI Functions als einzelnes Backend:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         }
       }
     ]
   }

2. Um eine authentication-Anforderungs-Policy zu erstellen, die für alle Routen in der API-Deployment-Spezifikation gilt, fügen Sie (sofern noch nicht vorhanden) einen requestPolicies-Bereich vor dem Abschnitt routes ein. Beispiel:

   
   {
     "requestPolicies": {},
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
            "type": "ORACLE_FUNCTIONS_BACKEND",
            "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         }
       }
     ]
   }

3. Fügen Sie die Anforderungs-Policy authentication wie folgt hinzu:

   
   {
     "requestPolicies": {
       "authentication": {
         "type": "TOKEN_AUTHENTICATION",
         <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>">,
         "tokenAuthScheme": "<authentication-scheme>",
         "isAnonymousAccessAllowed": <true|false>,
         "maxClockSkewInSeconds": <seconds-difference>,
         "validationPolicy": {<validation-policy-config>},
       }
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
            "type": "ORACLE_FUNCTIONS_BACKEND",
            "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         }
       }
     ]
   }

   Dabei gilt:

   • "authentication": {"type": "TOKEN_AUTHENTICATION"... gibt an, dass Sie Token für die Authentifizierung verwenden möchten.
   • <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>"> gibt an, ob es sich um einen Anforderungsheader handelt, der das Token enthält (wenn ja, wird der Name des Headers angegeben), oder ob es sich um einen Abfrageparameter handelt, der das Token enthält (wenn ja, wird der Name des Abfrageparameters angegeben. Beachten Sie, dass Sie entweder "tokenHeader": "<token-header-name>" oder "tokenQueryParam": "<token-query-param-name>"> angeben können, aber nicht beides. Beispiel: "tokenHeader": "Authorization"
   • <tokenAuthScheme> ist der Name des Authentifizierungsschemas, das verwendet werden soll, wenn das Token in einem Anforderungsheader enthalten ist. Beispiel: "Bearer".
   • "isAnonymousAccessAllowed": <true|false> gibt optional an, ob nicht authentifizierte (d.h. anonyme) Endbenutzer auf Routen in der API-Deployment-Spezifikation zugreifen können. Wenn Sie den Zugriff anonymer Endbenutzer auf Routen nie zulassen möchten, setzen Sie diese Eigenschaft auf false. Wenn Sie diese Eigenschaft nicht in die authentication-Policy aufnehmen, wird standardmäßig false verwendet. Hinweis: Wenn Sie diese Eigenschaft aufnehmen und auf true setzen, müssen Sie auch explizit jede Route angeben, auf die anonym zugegriffen werden kann. Setzen Sie dazu in der authorization-Policy jeder einzelnen Route die type-Eigenschaft auf "ANONYMOUS".
   • maxClockSkewInSeconds: <seconds-difference> gibt optional den maximalen Zeitunterschied zwischen den Systemuhren des Identitätsproviders, der ein JWT ausgestellt hat, und dem API-Gateway an. Der angegebene Wert wird berücksichtigt, wenn das API-Gateway das JWT validiert, um zu bestimmen, ob es noch gültig ist. Verwenden Sie dazu den Claim "nicht vor" (nbf, falls vorhanden) und den Ablaufclaim (exp) im JWT. Der Minimum (und Standardwert) ist 0, der Maximum ist 120.
   • "validationPolicy": {<validation-policy-config>} gibt eine Validierungs-Policy zum Validieren von Token an, wie in den folgenden Schritten beschrieben.
4. Wenn das API-Gateway sowohl JWT-Token als auch Nicht-JWT-Token mit einem Introspektionsendpunkt des OAuth 2.0-Autorisierungsservers mit Clientzugangsdaten validieren soll (einschließlich eines Client Secrets, das aus einem Vault im Vault-Service abgerufen wird), fügen Sie die folgende Validierungs-Policy dem leeren Abschnitt validationPolicy hinzu:

         "validationPolicy": {
           "type": "REMOTE_DISCOVERY",          
           "clientDetails": {
             "type": "CUSTOM",
             "clientId": "<client-id>",
             "clientSecretId": "<secret-ocid>",
             "clientSecretVersionNumber": <secret-version-number>
           },          
           "sourceUriDetails": {
             "type": "DISCOVERY_URI",
             "uri": "<well-known-uri>"
           },
           "isSslVerifyDisabled": <true|false>,
           "maxCacheDurationInHours": <cache-time>,
           "additionalValidationPolicy": {
             "issuers": ["<issuer-url>", "<issuer-url>"],
             "audiences": ["<intended-audience>"],
             "verifyClaims": [{
               "key": "<claim-name>",
               "values": ["<acceptable-value>", "<acceptable-value>"],
               "isRequired": <true|false>
             }]
           }
         }

   Dabei gilt:

   • "validationPolicy": {"type": "REMOTE_DISCOVERY"...} gibt an, dass Sie Token mit dem Introspektionsendpunkt eines OAuth 2.0-Autorisierungsservers mit Clientzugangsdaten (einschließlich eines Client Secrets, das aus einem Vault im Vault-Service abgerufen wird) validieren möchten.
   • clientDetails": {"type": "CUSTOM"...} gibt Details des Client Secrets an, das aus einem Vault im Vault-Service abgerufen werden soll:
     • "clientId": "<client-id>" gibt die Client-ID an, die an den Introspektionsendpunkt gesendet werden soll. Sie erhalten eine Client-ID, indem Sie eine Client-Anwendung beim Autorisierungsserver erstellen und registrieren. Beispiel: 5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1 . Siehe Voraussetzungen für die Tokenauthentifizierung.
     • "clientSecretId": "<secret-ocid>" gibt die OCID des Vault Secrets an, das das an den Introspektionsendpunkt zu sendende Client Secret enthält. Beispiel: ocid1.vaultsecret.oc1.iad.amaaaaaa______cggit3q
     • "clientSecretVersionNumber": <secret-version-number> gibt die Version des Vault Secrets an, das das an den Introspektionsendpunkt zu sendende Client Secret enthält. Beispiel: 1
   • "uri": "<well-known-uri>" gibt die bekannte URL eines Autorisierungsservers an, von dem das API-Gateway Autorisierungsmetadatenendpunkte abrufen soll. Beispiel: https://my-idp/oauth2/default/.well-known/openid-configuration. Beachten Sie, dass die URL aus dem Subnetz mit dem API-Gateway geroutet werden kann, in dem die API bereitgestellt wird.
   • "isSslVerifyDisabled": <true|false> gibt an, ob die SSL-Überprüfung bei der Kommunikation mit dem Autorisierungsserver deaktiviert werden soll. Oracle empfiehlt, diese Option nicht auf true festzulegen, weil sie die JWT-Validierung beeinträchtigen kann. API Gateway vertraut den Zertifikaten von mehreren Zertifizierungsstellen, die für OCI IAM mit Identitätsdomains, Oracle Identity Cloud Service (IDCS), Auth0 und Okta ausgestellt werden.
   • "maxCacheDurationInHours": <cache-time> gibt die Anzahl der Stunden (zwischen 1 und 24) an, in denen das API-Gateway die Antwort vom Introspektionsendpunkt cachen soll.
   • "additionalValidationPolicy": {"issuers": ...} gibt zusätzliche Details zur Tokenvalidierung an:
     • <issuer-url> ist die URL (oder eine Textzeichenfolge) für einen Autorisierungsserver, die im Ausstelleranspruch (iss) eines JWTs für den Zugriff auf das API-Deployment zulässig ist. Beispiel: Um einen von OCI IAM mit Identitätsdomains ausgegebenen JWT für den Zugriff auf das API-Deployment zu aktivieren, geben Sie https://identity.oraclecloud.com/ an. Sie können einen oder mehrere Autorisierungsserver angeben (max. fünf). Informationen hierzu finden Sie unter Identitätsproviderdetails für iss- und aud-Claims sowie für die JWKS-URI.
     • <intended-audience> ist ein Wert, der im Zielgruppenclaim (aud) eines JWT zur Identifikation des beabsichtigten Empfängers des Tokens zulässig ist. Beispiel: Die Zielgruppe kann (muss aber nicht) dem Hostnamen des API-Gateways entsprechen. Sie können eine oder mehrere Zielgruppen angeben (maximal fünf). Informationen hierzu finden Sie unter Identitätsproviderdetails für iss- und aud-Claims sowie für die JWKS-URI.
     • "verifyClaims": {...} gibt optional zusätzliche Claimnamen und -werte für einen oder mehrere zusätzliche Claims zur Überprüfung in einem JWT an (max. zehn):
       • "key": "<claim-name>" ist der Name eines Claims, der in einem JWT enthalten sein kann oder muss. Der Claimname, den Sie angeben, kann ein reservierter Claimname sein, wie der Subject-Claim (sub), oder ein benutzerdefinierter Claimname, der von einem bestimmten Autorisierungsserver ausgestellt wird.
       • "values": ["<acceptable-value>", "<acceptable-value>"] (optional) gibt einen oder mehrere zulässige Werte für den Claim an.
       • "isRequired": <true|false> gibt an, ob der Claim im JWT enthalten sein muss.

       Beachten Sie, dass alle eingegebenen Schlüsselnamen und -werte einfach wie Zeichenfolgen behandelt werden und exakt mit den Namen und Werten im JWT übereinstimmen müssen. Das Abgleichen von Mustern und andere Datentypen werden nicht unterstützt.

   Beispiel: Die folgende authentication-Policy konfiguriert das API-Gateway, um ein Token im Autorisierungsanforderungsheader mit Clientzugangsdaten (einschließlich eines Client Secrets, das von einem Vault im Vault-Service abgerufen wird) zu validieren, das an einen OAuth 2.0-Introspektionsendpunkt übergeben wird:

   {
     "requestPolicies": {
       "authentication": {
         "type": "TOKEN_AUTHENTICATION",
         "tokenHeader": "Authorization",
         "tokenAuthScheme": "Bearer",
         "isAnonymousAccessAllowed": false,
         "maxClockSkewInSeconds": 10,
         "validationPolicy": {
           "type": "REMOTE_DISCOVERY",
           "clientDetails": {
             "type": "CUSTOM",
             "clientId": "5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1",
             "clientSecretId": "ocid1.vaultsecret.oc1.iad.amaaaaaa______cggit3q",
             "clientSecretVersionNumber": 1
           },          
           "sourceUriDetails": {
             "type": "DISCOVERY_URI",
             "uri": "https://my-idp/oauth2/default/.well-known/openid-configuration"
           },
           "isSslVerifyDisabled": false,
           "maxCacheDurationInHours": 2,
           "additionalValidationPolicy": {
             "issuers": ["https://identity.oraclecloud.com/"],
             "audiences": ["api.dev.io"],
             "verifyClaims": [{
               "key": "is_admin",
               "values": ["service:app", "read:hello"],
               "isRequired": true
             }]
           }
         }
       }
     },
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         }
       }
     ]
   }

5. Wenn das API-Gateway JWTs validieren soll, indem öffentliche Verifizierungsschlüssel zur Laufzeit vom Identitätsprovider abgerufen werden, fügen Sie die folgende Validierungs-Policy zum leeren Abschnitt validationPolicy hinzu:

         "validationPolicy": {
           "type": "REMOTE_JWKS",
           "uri": "<uri-for-jwks>",
           "isSslVerifyDisabled": <true|false>,
           "maxCacheDurationInHours": <cache-time>,
           "additionalValidationPolicy": {
             "issuers": ["<issuer-url>", "<issuer-url>"],
             "audiences": ["<intended-audience>"],
             "verifyClaims": [{
               "key": "<claim-name>",
               "values": ["<acceptable-value>", "<acceptable-value>"],
               "isRequired": <true|false>
             }]
           }
         }
   

   Dabei gilt:

   • "validationPolicy": {"type": "REMOTE_JWKS"... gibt an, dass Sie das API-Gateway so konfigurieren möchten, dass bis zu zehn öffentliche Prüfschlüssel zur Laufzeit vom Identitätsprovider abgerufen werden.
   • "uri": "<uri-for-jwks>" gibt die URI an, von der das JSON Web Key Set (JWKS) abgerufen werden soll, mit dem die Signatur der JWTs verifiziert werden soll. Weitere Informationen über die anzugebende URI finden Sie unter Identitätsproviderdetails für iss- und aud-Claims sowie für die JWKS-URI. Beachten Sie dabei Folgendes:
     • Die URI muss aus dem Subnetz mit dem API-Gateway geroutet werden können, in dem die API bereitgestellt wird.
     • Wenn das API-Gateway das JWKS nicht abrufen kann, geben alle Anforderungen an das API-Deployment einen HTTP 500-Antwortcode zurück. Weitere Informationen zum Fehler finden Sie im Ausführungslog des API-Gateways (siehe Logging zu API-Deployments hinzufügen).
     • Bestimmte Schlüsselparameter müssen im JWKS vorhanden sein, um die JWT-Signatur zu verifizieren (siehe Erforderliche Schlüsselparameter zum Überprüfen von JWT-Signaturen).
     • Das JWKS kann bis zu zehn Schlüssel enthalten.
   • "isSslVerifyDisabled": <true|false> gibt an, ob die SSL-Überprüfung bei der Kommunikation mit dem Identitätsprovider deaktiviert werden soll. Oracle empfiehlt, diese Option nicht auf true festzulegen, weil sie die JWT-Validierung beeinträchtigen kann. API Gateway vertraut den Zertifikaten von mehreren Zertifizierungsstellen, die für OCI IAM mit Identitätsdomains, Oracle Identity Cloud Service (IDCS), Auth0 und Okta ausgestellt werden.
   • "maxCacheDurationInHours": <cache-time> gibt an, wie viele Stunden (zwischen 1 und 24) lang das API-Gateway das JWKS nach dem Abrufen cachen soll.
   • "additionalValidationPolicy": {"issuers": ...} gibt zusätzliche Details zur Tokenvalidierung an:
     • <issuer-url> ist die URL (oder eine Textzeichenfolge) für einen Identitätsprovider, die im Ausstelleranspruch (iss) eines JWTs für den Zugriff auf das API-Deployment zulässig ist. Beispiel: Um den Zugriff auf das API-Deployment über ein von OCI IAM mit Identitätsdomains ausgestelltes JWT zu ermöglichen, geben Sie https://identity.oraclecloud.com/ ein. Sie können einen oder mehrere Identitätsprovider angeben (maximal fünf). Informationen hierzu finden Sie unter Identitätsproviderdetails für iss- und aud-Claims sowie für die JWKS-URI.
     • <intended-audience> ist ein Wert, der im Zielgruppenclaim (aud) eines JWT zur Identifikation des beabsichtigten Empfängers des Tokens zulässig ist. Beispiel: Die Zielgruppe kann (muss aber nicht) dem Hostnamen des API-Gateways entsprechen. Sie können eine oder mehrere Zielgruppen angeben (maximal fünf). Informationen hierzu finden Sie unter Identitätsproviderdetails für iss- und aud-Claims sowie für die JWKS-URI.
     • verifyClaims gibt optional zusätzliche Claimnamen und -werte für einen oder mehrere zusätzliche Claims zur Überprüfung in einem JWT an (maximal zehn).
       • "key": "<claim-name>" ist der Name eines Claims, der in einem JWT enthalten sein kann oder muss. Der angegebene Claimname kann ein reservierter Claimname sein, wie der Subject-Claim (sub), oder ein benutzerdefinierter Claimname, der von einem bestimmten Identitätsprovider ausgestellt wird.
       • "values": ["<acceptable-value>", "<acceptable-value>"] (optional) gibt einen oder mehrere zulässige Werte für den Claim an.
       • "isRequired": <true|false> gibt an, ob der Claim im JWT enthalten sein muss.

       Beachten Sie, dass alle eingegebenen Schlüsselnamen und -werte einfach wie Zeichenfolgen behandelt werden und exakt mit den Namen und Werten im JWT übereinstimmen müssen. Das Abgleichen von Mustern und andere Datentypen werden nicht unterstützt.

   Beispiel: Mit der folgenden authentication-Policy wird das API-Gateway so konfiguriert, dass das JWT im Autorisierungsanforderungsheader validiert wird, indem öffentliche Verifizierungsschlüssel zur Laufzeit vom Identitätsprovider abgerufen werden:

   {
     "requestPolicies": {
       "authentication": {
         "type": "TOKEN_AUTHENTICATION",
         "tokenHeader": "Authorization",
         "tokenAuthScheme": "Bearer",
         "isAnonymousAccessAllowed": false,
         "validationPolicy": {
           "type": "REMOTE_JWKS",
           "uri": "https://my-tenant-id.identity.oraclecloud.com/admin/v1/SigningCert/jwk",
           "isSslVerifyDisabled": false,
           "maxCacheDurationInHours": 2,
           "additionalValidationPolicy": {
             "issuers": ["https://identity.oraclecloud.com/"],
             "audiences": ["api.dev.io"],
             "verifyClaims": [{
               "key": "is_admin",
               "values": ["service:app", "read:hello"],
               "isRequired": true
             }]
           }
         }
       }
     },
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         }
       }
     ]
   }

6. Wenn das API-Gateway JWTs mit öffentlichen Verifizierungsschlüsseln validieren soll, die bereits von einem Identitätsprovider ausgestellt wurden (damit das API-Gateway JWTs lokal verifizieren kann, ohne den Identitätsprovider kontaktieren zu müssen), fügen Sie die folgende Validierungs-Policy zum leeren Abschnitt validationPolicy hinzu:

         "validationPolicy": {
           "type": "STATIC_KEYS",
           "keys": [{<key-config>}],
           "isSslVerifyDisabled": <true|false>,
           "maxCacheDurationInHours": <cache-time>,
           "additionalValidationPolicy": {
             "issuers": ["<issuer-url>", "<issuer-url>"],
             "audiences": ["<intended-audience>"],
             "verifyClaims": [{
               "key": "<claim-name>",
               "values": ["<acceptable-value>", "<acceptable-value>"],
               "isRequired": <true|false>
             }]
           }
         }

   Dabei gilt:

   • "validationPolicy": {"type": "STATIC_KEYS"... gibt an, dass Sie das API-Gateway mit bis zu zehn öffentlichen Prüfschlüsseln konfigurieren möchten, die bereits von einem Identitätsprovider ausgestellt wurden. (Dadurch kann das API-Gateway JWTs lokal verifiziert werden, ohne dass Sie den Identitätsprovider kontaktieren müssen).
   • "keys": [{<key-config>}] geben Sie die ID des statischen Schlüssels an, mit dem das JWT signiert wird. Die anzugebenden Details hängen vom Format des Schlüssels ab, der bereits vom Identitätsprovider ausgegeben wurde (unabhängig vom Format können Sie bis zu zehn Schlüssel angeben):

     • Wenn es sich bei dem statischen Schlüssel um einen JSON Web Key handelt, geben Sie "format": "JSON_WEB_KEY" an, geben Sie die ID des statischen Schlüssels zum Signieren des JWT als Wert des "kid"-Parameters an, und geben Sie Werte für weitere Parameter zur Überprüfung der JWT-Signatur an.

       Beispiel:

               "keys": [
                 {
                   "format": "JSON_WEB_KEY",
                   "kid": "master_key",
                   "kty": "RSA",
                   "n": "0vx7agoebGc...KnqDKgw",
                   "e": "AQAB",
                   "alg": "RS256",
                   "use": "sig"
                 }
               ]

       Beachten Sie, dass bestimmte Parameter im statischen Schlüssel vorhanden sein müssen, um die JWT-Signatur zu verifizieren (siehe Erforderliche Schlüsselparameter zum Überprüfen von JWT-Signaturen). Beachten Sie auch, dass RSA derzeit der einzige unterstützte Schlüsseltyp (kty) ist.

     • Wenn es sich bei dem statischen Schlüssel um einen PEM-codierten Public Key handelt, geben Sie "format": "PEM" an, geben Sie die ID des statischen Schlüssels zum Signieren des JWT als Wert von "kid" an, und geben Sie den Schlüssel als Wert von "key" an.

       Beispiel:

               "keys": [
                 {
                   "format": "PEM",
                   "kid": "master_key"
                   "key": -----BEGIN PUBLIC KEY-----XsEiCeYgglwW/KAhSSNRVdD60QlXYMWHOhXzSFDZCLf1WXxKMZCiMvVrsBIzmFEXnFmcsO2mxwlL5/8qQudomoP+yycJ2gWPIgqsZcQRheJWxVC5ep0MeEHlvLnEvCi9utpAnjrsZCQ7plfZVPX7XORvezwqQhBfYzwA27M2FgOOs8DOIYfqQ1Ki3DMqEppFnjLcjgQtknbTlT7YgG6tzobwig8M2KIrPjJ0BmbJAFH-----END PUBLIC KEY-----
                 }
               ]

       Beachten Sie, dass die Marker -----BEGIN PUBLIC KEY----- und -----END PUBLIC KEY----- erforderlich sind.

   • "isSslVerifyDisabled": <true|false> gibt an, ob die SSL-Überprüfung bei der Kommunikation mit dem Identitätsprovider deaktiviert werden soll. Oracle empfiehlt, diese Option nicht auf true festzulegen, weil sie die JWT-Validierung beeinträchtigen kann. API Gateway vertraut den Zertifikaten von mehreren Zertifizierungsstellen, die für OCI IAM mit Identitätsdomains, Oracle Identity Cloud Service (IDCS), Auth0 und Okta ausgestellt werden.
   • "maxCacheDurationInHours": <cache-time> gibt an, wie viele Stunden (zwischen 1 und 24) lang das API-Gateway das JWKS nach dem Abrufen cachen soll.
   • "additionalValidationPolicy": {"issuers": ...} gibt zusätzliche Details zur Tokenvalidierung an:
     • <issuer-url> ist die URL (oder eine Textzeichenfolge) für einen Identitätsprovider, die im Ausstelleranspruch (iss) eines JWTs für den Zugriff auf das API-Deployment zulässig ist. Beispiel: Um den Zugriff auf das API-Deployment über ein von OCI IAM mit Identitätsdomains ausgestelltes JWT zu ermöglichen, geben Sie https://identity.oraclecloud.com/ ein. Sie können einen oder mehrere Identitätsprovider angeben (maximal fünf). Informationen hierzu finden Sie unter Identitätsproviderdetails für iss- und aud-Claims sowie für die JWKS-URI.
     • <intended-audience> ist ein Wert, der im Zielgruppenclaim (aud) eines JWT zur Identifikation des beabsichtigten Empfängers des Tokens zulässig ist. Beispiel: Die Zielgruppe kann (muss aber nicht) dem Hostnamen des API-Gateways entsprechen. Sie können eine oder mehrere Zielgruppen angeben (maximal fünf). Informationen hierzu finden Sie unter Identitätsproviderdetails für iss- und aud-Claims sowie für die JWKS-URI.
     • verifyClaims gibt optional zusätzliche Claimnamen und -werte für einen oder mehrere zusätzliche Claims zur Überprüfung in einem JWT an (maximal zehn).
       • "key": "<claim-name>" ist der Name eines Claims, der in einem JWT enthalten sein kann oder muss. Der angegebene Claimname kann ein reservierter Claimname sein, wie der Subject-Claim (sub), oder ein benutzerdefinierter Claimname, der von einem bestimmten Identitätsprovider ausgestellt wird.
       • "values": ["<acceptable-value>", "<acceptable-value>"] (optional) gibt einen oder mehrere zulässige Werte für den Claim an.
       • "isRequired": <true|false> gibt an, ob der Claim im JWT enthalten sein muss.

       Beachten Sie, dass alle eingegebenen Schlüsselnamen und -werte einfach wie Zeichenfolgen behandelt werden und exakt mit den Namen und Werten im JWT übereinstimmen müssen. Das Abgleichen von Mustern und andere Datentypen werden nicht unterstützt.

   Beispiel: Die folgende authentication-Policy konfiguriert das API-Gateway mit einem öffentlichen Verifizierungsschlüssel, der bereits von einem Identitätsprovider ausgegeben wurde, um das JWT im Autorisierungsanforderungsheader zu validieren:

   {
     "requestPolicies": {
       "authentication": {
         "type": "TOKEN_AUTHENTICATION",
         "tokenHeader": "Authorization",
         "tokenAuthScheme": "Bearer",
         "isAnonymousAccessAllowed": false,
         "validationPolicy": {
           "type": "STATIC_KEYS",
           "keys": [
             {
               "format": "JSON_WEB_KEY",
               "kid": "master_key",
               "kty": "RSA",
               "n": "0vx7agoebGc...KnqDKgw",
               "e": "AQAB",
               "alg": "RS256",
               "use": "sig"
             }
           ],
           "isSslVerifyDisabled": false,
           "maxCacheDurationInHours": 2,
           "additionalValidationPolicy": {
             "issuers": ["https://identity.oraclecloud.com/"],
             "audiences": ["api.dev.io"],
             "verifyClaims": [{
               "key": "is_admin",
               "values": ["service:app", "read:hello"],
               "isRequired": true
             }]
           }
         }
       }
     },
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         }
       }
     ]
   }

7. (Optional) Sie können angeben, wie das API-Gateway eine nicht erfolgreiche Authentifizierungsantwort verarbeiten soll (nach einem nicht erfolgreichen Versuch, ein fehlendes oder ungültiges Token zu validieren), indem Sie eine Validierungsfehler-Policy einrichten:
   1. Wenn das API-Gateway einen HTTP 401-Statuscode und den WWW-Authenticate-Header in der Antwort senden soll (die Standardantwort auf ein fehlendes oder ungültiges Token), definieren Sie keine Validierungsfehler-Policy.

   2. Wenn das API-Gateway einen OpenID Connect-Autorisierungsfluss zum Abrufen eines neuen JWT-Zugriffstokens verwenden soll, definieren Sie eine Validierungsfehler-Policy vom Typ OAUTH2. Beachten Sie, dass diese Option nur verfügbar ist, wenn Sie zuvor eine validationPolicy vom Typ REMOTE_DISCOVERY angegeben haben. Wählen Sie eine der folgenden Optionen aus:

      {
        "requestPolicies": {
          "authentication": {
            "type": "TOKEN_AUTHENTICATION",
            ...
            "validationPolicy": {
              "type": "REMOTE_DISCOVERY",
              ...
            },
            "validationFailurePolicy": {
              "type": "OAUTH2",
              "scopes": ["<scope>", "<scope"],
              "clientDetails": {
                "type": "<VALIDATION_BLOCK|CUSTOM>",
                "clientId": "<client-id>",
                "clientSecretId": "<secret-ocid>",
                "clientSecretVersionNumber": <secret-version-number>
                },
              "sourceUriDetails": {
                "type": "VALIDATION_BLOCK"
                },
              "maxExpiryDurationInHours": <number-of-hours>,
              "useCookiesForSession": <true|false>,
              "useCookiesForIntermediateSteps": <true|false>,
              "usePkce": <true|false>,
              "responseType": "code",
              "fallbackRedirectPath": "<redirect-path>",
              "logoutPath": "<logout-path>"
            }
          }
        },
        "routes": [
          ...
        ]
      }

      Dabei gilt:

      • "scopes": ["<scope>", "<scope"] gibt einen oder mehrere Zugriffsgeltungsbereiche an, die in einen scope-Claim aufgenommen werden sollen, der an den Autorisierungsserver gesendet wird. Um den OpenID Connect-Autorisierungsablauf zu verwenden, müssen Sie openid als einen der Geltungsbereiche aufnehmen. Beispiel: "scopes": ["openid", "email:read", "profile"]
      • clientDetails": {...} gibt die Clientdetails an, mit denen ein neues JWT-Zugriffstoken vom Autorisierungsserver abgerufen werden soll:
        • "type": "<VALIDATION_BLOCK|CUSTOM>" gibt an, ob dieselben oder andere Clientdetails wie in der vorherigen validationPolicy angegeben verwendet werden sollen. Wenn Sie dieselben Clientdetails wie zuvor verwenden möchten (was in der Regel der Fall ist), geben Sie "type": "VALIDATION_BLOCK" an, und geben Sie keine weiteren Details an. Wenn Sie andere Clientdetails verwenden möchten, geben Sie "type": "CUSTOM" an, und legen Sie Werte für "clientId", "clientSecretId" und "clientSecretVersionNumber" fest.
        • "clientId": "<client-id>" gibt die Client-ID an, die an den Introspektionsendpunkt gesendet werden soll. Wird nur verwendet, wenn "type": "CUSTOM". Beispiel: 5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1
        • "clientSecretId": "<secret-ocid>" gibt die OCID des Vault Secrets an, das das an den Introspektionsendpunkt zu sendende Client Secret enthält. Wird nur verwendet, wenn "type": "CUSTOM". Beispiel: ocid1.vaultsecret.oc1.iad.amaaaaaa______cggit3q
        • "clientSecretVersionNumber": <secret-version-number> gibt die Version des Vault Secrets an, das das an den Introspektionsendpunkt zu sendende Client Secret enthält. Wird nur verwendet, wenn "type": "CUSTOM". Beispiel: 1
      • "sourceUriDetails": {"type": "VALIDATION_BLOCK"} gibt an, dass Sie dieselbe URL wie in der vorherigen validationPolicy als bekannte URL eines Autorisierungsservers verwenden möchten, von dem das API-Gateway Autorisierungsmetadatenendpunkte abrufen soll.
      • "maxExpiryDurationInHours": <number-of-hours> gibt an, wie lange das vom Autorisierungsfluss generierte JWT-Token gecacht werden soll. Der Standardwert ist 1.
      • "useCookiesForSession": <true|false> gibt an, wie neu generierte JWT-Token als nicht menschenlesbare Zeichenfolgen am Ende eines OpenID Connect-Autorisierungsablaufs gespeichert werden:
        • Setzen Sie diese Option auf true, wenn Sie das neue JWT-Token in einem Sessioncookie speichern möchten. Um potenzielle CSRF-Angriffe zu verhindern, gibt das API-Gateway, wenn es das Token in einem Sessioncookie speichert, auch ein CSRF-Token in einem X-CSRF-TOKEN-Antwortheader zurück. Nachfolgende Anforderungen (außer GET-Anforderungen) müssen das CSRF-Token in einem X-CSRF-TOKEN-Anforderungsheader enthalten, zusätzlich zum JWT-Token im automatisch eingeschlossenen Sessioncookie.
        • Setzen Sie diese Option auf false, wenn Sie das neue JWT-Token nicht in einem Sessioncookie speichern möchten. Stattdessen gibt das API-Gateway ein nicht menschenlesbares Token in einem X-APIGW-TOKEN-Antwortheader zurück. Nachfolgende Anforderungen an das API-Gateway müssen dasselbe Token in einem X-APIGW-TOKEN-Anforderungsheader enthalten.

        Siehe Hinweise zum Schutz vor Cross-Site Request Forgery (CSRF)

      • "useCookiesForIntermediateSteps": <true|false> gibt an, wie Zwischenschrittwerte des Autorisierungsablaufs gespeichert werden (z.B. Anforderungsparameter). Setzen Sie diese Option auf true, um die Werte in Browser-Cookies zu speichern. Setzen Sie diese Option auf false, um die Werte im API-Gateway zu speichern.
      • "usePkce": <true|false> gibt an, ob PKCE (Proof Key for Code Exchange) für zusätzliche Sicherheit verwendet werden soll. PKCE ist eine OAuth 2.0-Sicherheitserweiterung zur Verhinderung von CSRF (Cross-Site Request Forgery) und Autorisierungscode-Injection-Angriffen. PKCE ist kein Ersatz für ein Client Secret, und PKCE wird auch dann empfohlen, wenn ein Client Secret verwendet wird. Weitere Informationen zu PKCE finden Sie in der OAuth 2.0-Dokumentation.
      • "responseType": "code" gibt den Antworttyp an, der für den Autorisierungsablauf erforderlich ist. Geben Sie code als Antworttyp an.
      • "fallbackRedirectPath": "/home" gibt optional einen relativen Pfad im aktuellen API-Deployment an, an den API-Clients umgeleitet werden sollen, wenn die ursprüngliche Anforderung eine PUT-Anforderung oder eine POST-Anforderung war. Beispiel: /home.

        Wenn die ursprüngliche Anforderung eine GET-Anforderung war, wird die Anforderungsverarbeitung mit einem neuen JWT-Zugriffstoken fortgesetzt, sodass kein Fallback-Pfad verwendet wird.

      • "logoutPath": "<revoke-path>"gibt optional einen relativen Pfad zu einem Abmelde-Backend im aktuellen API-Deployment an. Der angegebene Pfad muss mit dem Routenpfad übereinstimmen, der für das Abmelde-Backend definiert ist. Beispiel: "logoutPath": "/revoke".

        Ein API-Client kann das Backend für die Abmeldung aufrufen, um Token zu entziehen. Ein Aufruf des Abmelde-Backends kann eine URL nach der Abmeldung als Abfrageparameter mit dem Namen postLogoutUrl enthalten. Siehe Abmeldung als API-Gateway-Backend hinzufügen.

      Beispiel:

      {
        "requestPolicies": {
          "authentication": {
            "type": "TOKEN_AUTHENTICATION",
            ...
            "validationPolicy": {
              "type": "REMOTE_DISCOVERY",
              ...
            },
            "validationFailurePolicy": {
              "type": "OAUTH2",
              "scopes": ["openid", "email:read", "profile"],
              "clientDetails": {
                "type": "VALIDATION_BLOCK"
                },
              "sourceUriDetails": {
                "type": "VALIDATION_BLOCK"
              },
              "maxExpiryDurationInHours": 2,
              "useCookiesForSession": true,
              "useCookiesForIntermediateSteps": true,
              "usePkce": true,
              "responseType": "code",
              "fallbackRedirectPath": "/home",
              "logoutPath": "/revoke"
            }
          }
        },
        "routes": [
          ...
        ]
      }

   3. Wenn Sie die Antwort an einen nicht erfolgreichen Versuch anpassen möchten, ein fehlendes oder ungültiges Token zu validieren, definieren Sie eine Validierungsfehler-Policy vom Typ MODIFY_RESPONSE, und geben Sie wie folgt einen Statuscode (und einen optionalen Nachrichtentext) an, der an den API-Client zurückgegeben werden soll:

      {
        "requestPolicies": {
          "authentication": {
            "type": "TOKEN_AUTHENTICATION",
            ...
            "validationPolicy": {
              ...
            },
            "validationFailurePolicy": {
              "type": "MODIFY_RESPONSE",
              "responseCode": "<alternative-response-code>",
              "responseMessage": "<custom-message-body>",
              "responseTransformations": {
                "headerTransformations": {
                  <valid-header-transformation-response-policy>
                }
              }
            }
          }
        },
        "routes": [
          ...
        ]
      }

      Dabei gilt:

      • responseCode: Gibt einen alternativen HTTP-Statuscode an. Beispiel, 500.
      • responseMessage: (optional) Gibt einen Nachrichtentext an. Beispiel: Unfortunately, authentication failed. Der Nachrichtentext kann eine beliebige Kontextvariable enthalten (mit Ausnahme von request.body).
      • responseTransformations: (optional) ändert die Header der Antwort, die das API-Gateway an den API-Client zurückgibt, indem eine Headertransformationsantwort-Policy angegeben wird. Weitere Informationen zu Headertransformations-Policys finden Sie unter Headertransformationsantwort-Policys hinzufügen.

      Beispiel:

      {
        "requestPolicies": {
          "authentication": {
            "type": "TOKEN_AUTHENTICATION",
            ...
            "validationPolicy": {
              ...
            },
            "validationFailurePolicy": {
              "type": "MODIFY_RESPONSE",
              "responseCode": "500",
              "responseMessage": "Unfortunately, authentication failed.",
            }
          }
        },
        "routes": [
          ...
        ]
      }

8. Fügen Sie eine authorization-Anforderungs-Policy für jede Route in der API-Deployment-Spezifikation hinzu:

   1. Fügen Sie, falls noch nicht vorhanden, einen requestPolicies-Abschnitt nach dem backend-Abschnitt der ersten Route ein. Beispiel:

      {
        "requestPolicies": {
          "authentication": {
            "type": "TOKEN_AUTHENTICATION",
            "tokenHeader": "Authorization",
            "tokenAuthScheme": "Bearer",
            "isAnonymousAccessAllowed": false,
            "validationPolicy": {
              "type": "STATIC_KEYS",
              "keys": [
                {
                  "format": "JSON_WEB_KEY",
                  "kid": "master_key",
                  "kty": "RSA",
                  "n": "0vx7agoebGc...KnqDKgw",
                  "e": "AQAB",
                  "alg": "RS256",
                  "use": "sig"
                }
              ],
              "isSslVerifyDisabled": false,
              "maxCacheDurationInHours": 2,
              "additionalValidationPolicy": {
                "issuers": ["https://identity.oraclecloud.com/"],
                "audiences": ["api.dev.io"],
                "verifyClaims": [{
                  "key": "is_admin",
                  "values": ["service:app", "read:hello"],
                  "isRequired": true
                }]
              }
            }
          }
        },
        "routes": [
          {
            "path": "/hello",
            "methods": ["GET"],
            "backend": {
              "type": "ORACLE_FUNCTIONS_BACKEND",
              "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
            },
            "requestPolicies": {}
          }
        ]
      }

   2. Fügen Sie die folgende authorization-Policy zum neuen requestPolicies-Abschnitt hinzu:

            "requestPolicies": {
              "authorization": {
                "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS">, 
                "allowedScope": [ "<scope>" ]
              }
            }

      Dabei gilt:

      • "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS"> gibt an, wie Zugriff auf die Route erteilt werden soll:

        • "AUTHENTICATION_ONLY": Zugriff wird nur Endbenutzern erteilt, die erfolgreich authentifiziert wurden. In diesem Fall zeigt die "isAnonymousAccessAllowed"-Eigenschaft in der authentication-Policy der API-Deployment-Spezifikation keine Wirkung.
        • "ANY_OF": Zugriff wird nur Endbenutzern erteilt, die erfolgreich authentifiziert wurden, sofern der scope-Claim des JWT einen der Zugriffsgeltungsbereiche enthält, die Sie in der Eigenschaft allowedScope angeben. In diesem Fall zeigt die "isAnonymousAccessAllowed"-Eigenschaft in der authentication-Policy der API-Deployment-Spezifikation keine Wirkung.
        • "ANONYMOUS": Zugriff wird allen Endbenutzern erteilt, selbst wenn diese nicht erfolgreich authentifiziert wurden. In diesem Fall müssen Sie die "isAnonymousAccessAllowed"-Eigenschaft in der authentication-Policy der API-Deployment-Spezifikation explizit auf true setzen.
      • "allowedScope": [ "<scope>" ] ist eine kommagetrennte Liste mit mindestens einer Zeichenfolge, die einem im scope-Claim des JWT enthaltenen Zugriffsgeltungsbereich entspricht. In diesem Fall müssen Sie die type-Eigenschaft auf "ANY_OF" setzen (die "allowedScope"-Eigenschaft wird ignoriert, wenn die type-Eigenschaft auf "AUTHENTICATION_ONLY" oder "ANONYMOUS" gesetzt wurde). Wenn Sie mehr als einen Geltungsbereich angeben, wird der Zugriff auf die Route erteilt, sobald einer der angegebenen Geltungsbereiche im scope-Claim des JWT enthalten ist.

      Beispiel: Die folgende Anforderungs-Policy definiert eine /hello-Route, die nur authentifizierten Endbenutzern mit dem Geltungsbereich read:hello Zugriff gewährt:

      {
        "requestPolicies": {
          "authentication": {
            "type": "TOKEN_AUTHENTICATION",
            "tokenHeader": "Authorization",
            "tokenAuthScheme": "Bearer",
            "isAnonymousAccessAllowed": false,
            "validationPolicy": {
              "type": "STATIC_KEYS",
              "keys": [
                {
                  "format": "JSON_WEB_KEY",
                  "kid": "master_key",
                  "kty": "RSA",
                  "n": "0vx7agoebGc...KnqDKgw",
                  "e": "AQAB",
                  "alg": "RS256",
                  "use": "sig"
                }
              ],
              "isSslVerifyDisabled": false,
              "maxCacheDurationInHours": 2,
              "additionalValidationPolicy": {
                "issuers": ["https://identity.oraclecloud.com/"],
                "audiences": ["api.dev.io"],
                "verifyClaims": [{
                  "key": "is_admin",
                  "values": ["service:app", "read:hello"],
                  "isRequired": true
                }]
              }
            }
          }
        },
        "routes": [
          {
            "path": "/hello",
            "methods": ["GET"],
            "backend": {
              "type": "ORACLE_FUNCTIONS_BACKEND",
              "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
            },
            "requestPolicies": {
              "authorization": {
                "type": "ANY_OF",
                "allowedScope": [ "read:hello" ]
              }
            }
          }
        ]
      }

   3. Fügen Sie eine authorization-Anforderungs-Policy für alle restlichen Routen in der API-Deployment-Spezifikation hinzu.
   Hinweis
   
   

   Wenn Sie keine authorization-Policy für eine bestimmte Route angeben, wird der Zugriff basierend auf der Annahme erteilt, dass eine solche Policy vorhanden ist, und die type-Eigenschaft wird auf "AUTHENTICATION_ONLY" gesetzt. Anders ausgedrückt: Ungeachtet der Einstellung der isAnonymousAccessAllowed-Eigenschaft in der authentication-Policy der API-Deployment-Spezifikation können:

   • nur authentifizierte Endbenutzer auf die Route zugreifen
   • alle authentifizierten Endbenutzer unabhängig von den Zugriffsgeltungsbereichen im scope-Claim des JWT auf die Route zugreifen
   • anonyme Endbenutzer nicht auf die Route zugreifen
9. Speichern Sie die JSON-Datei, die die API-Deployment-Spezifikation enthält.

10. Verwenden Sie die API-Deployment-Spezifikation, wenn Sie ein API-Deployment wie folgt erstellen oder aktualisieren:

    • Durch Angabe der JSON-Datei in der Konsole bei Auswahl der Option Vorhandene API hochladen
    • Durch Angabe der JSON-Datei in einer Anforderung an die REST-API von API-Gateway

    Weitere Informationen finden Sie unter API durch das Erstellen eines API-Deployment in einem API-Gateway bereitstellen und API-Gateway aktualisieren.

11. (Optional) Bestätigen Sie, dass die API erfolgreich bereitgestellt wurde, indem Sie sie aufrufen (siehe In einem API-Gateway bereitgestellte API aufrufen).

Der Identitätsprovider, der das JWT ausgestellt hat, bestimmt die zulässigen Werte, die Sie für den Ausstellerclaim (iss) und den Zielgruppenclaim (aud) im JWT angeben müssen. Von dem Identitätsprovider, der das JWT ausgestellt hat, hängt auch die URI ab, von der das JSON Web Key Set (JWKS) abgerufen werden soll, mit dem die Signatur im JWT verifiziert werden soll.

Beachten Sie, dass ein JWKS unabhängig vom Identitätsprovider maximal zehn Schlüssel enthalten kann.

In der folgenden Tabelle finden Sie die Angaben für JWTs, die von den Identitätsanbietern OCI IAM mit Identitätsdomains, Oracle Identity Cloud Service (IDCS), Okta und Auth0 ausgestellt werden.

Um die Signatur in einem JWT zu überprüfen, müssen in API-Gateways die folgenden Schlüsselparameter in dem JWKS, das von einer URI zurückgegeben wird, oder im angegebenen statischen JSON Web Key enthalten sein.

Wenn Sie eine Authentifizierungsanforderungs-Policy des Typs JWT_AUTHENTICATION verwenden, müssen Endbenutzer ein JWT von einem Identitätsprovider abrufen, bevor sie auf ein API-Deployment zugreifen können, das JWTs zur Authentifizierung und Autorisierung verwendet.

Beim Aufrufen einer API, die in einem API-Gateway bereitgestellt ist, stellt der API-Client das JWT als Abfrageparameter oder im Header der Anforderung bereit. Das API-Gateway validiert das JWT mit einem entsprechenden öffentlichen Prüfschlüssel, der vom ausstellenden Identitätsprovider bereitgestellt wird. Mit der Policy der JWT_AUTHENTICATION-Authentifizierungsanforderung des API-Deployment können Sie konfigurieren, wie das API-Gateway JWTs validiert:

• Sie können das API-Gateway so konfigurieren, dass öffentliche Prüfschlüssel zur Laufzeit vom Identitätsprovider abgerufen werden. In diesem Fall fungiert der Identitätsprovider als Autorisierungsserver.
• Sie können das API-Gateway im Voraus mit öffentlichen Prüfschlüsseln konfigurieren, die bereits von einem Identitätsprovider ausgestellt wurden (sogenannte "statische Schlüssel"). So kann das API-Gateway JWTs zur Laufzeit lokal verifizieren, ohne den Identitätsprovider kontaktieren zu müssen. Das Ergebnis ist eine schnellere Tokenvalidierung.

So fügen Sie eine neue JWT_AUTHENTICATION-Authentifizierungs- und Autorisierungsanforderungs-Policy zu einer API-Deployment-Spezifikation in einer JSON-Datei hinzu:

1. Fügen Sie eine authentication-Anforderungs-Policy hinzu, die für alle Routen in der API-Deployment-Spezifikation gilt:

   1. Fügen Sie, falls noch nicht vorhanden, einen requestPolicies-Abschnitt vor dem routes-Abschnitt ein. Beispiel:

      
      {
        "requestPolicies": {},
        "routes": [
          {
            "path": "/hello",
            "methods": ["GET"],
            "backend": {
               "type": "ORACLE_FUNCTIONS_BACKEND",
               "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
            }
          }
        ]
      }

   2. Fügen Sie die folgende authentication-Policy zum neuen requestPolicies-Abschnitt hinzu.

      {
        "requestPolicies": {
          "authentication": {
            "type": "JWT_AUTHENTICATION",
            "isAnonymousAccessAllowed": <true|false>,
            "issuers": ["<issuer-url>", "<issuer-url>"],
            <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>">,
            "tokenAuthScheme": "<authentication-scheme>",
            "audiences": ["<intended-audience>"],
            "publicKeys": {
              "type": <"REMOTE_JWKS"|"STATIC_KEYS">,
              <public-key-config>
            },
            "verifyClaims": [
              {"key": "<claim-name>",
               "values": ["<acceptable-value>", "<acceptable-value>"],
               "isRequired": <true|false>
              }
            ],
            "maxClockSkewInSeconds": <seconds-difference>
          }
        },
        "routes": [
          {
            "path": "/hello",
            "methods": ["GET"],
            "backend": {
              "type": "ORACLE_FUNCTIONS_BACKEND",
              "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
            }
          }
        ]
      }

      Dabei gilt:

      • "isAnonymousAccessAllowed": <true|false> gibt optional an, ob nicht authentifizierte (d.h. anonyme) Endbenutzer auf Routen in der API-Deployment-Spezifikation zugreifen können. Wenn Sie den Zugriff anonymer Endbenutzer auf Routen nie zulassen möchten, setzen Sie diese Eigenschaft auf false. Wenn Sie diese Eigenschaft nicht in die authentication-Policy aufnehmen, wird standardmäßig false verwendet. Hinweis: Wenn Sie diese Eigenschaft aufnehmen und auf true setzen, müssen Sie auch explizit jede Route angeben, auf die anonym zugegriffen werden kann. Setzen Sie dazu in der authorization-Policy jeder einzelnen Route die type-Eigenschaft auf "ANONYMOUS".
      • <issuer-url> ist die URL (oder eine Textzeichenfolge) für einen Identitätsprovider, die im Ausstellerclaim (iss) eines JWT für den Zugriff auf das API-Deployment zulässig ist. Beispiel: Um den Zugriff auf das API-Deployment über ein von OCI IAM mit Identitätsdomains ausgestelltes JWT zu ermöglichen, geben Sie https://identity.oraclecloud.com/ ein. Sie können einen oder mehrere Identitätsprovider angeben (maximal fünf). Informationen hierzu finden Sie unter Identitätsproviderdetails für iss- und aud-Claims sowie für die JWKS-URI.
      • <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>"> gibt an, ob es sich um einen Anforderungsheader handelt, der das JWT enthält (wenn ja, wird der Name des Headers angegeben), oder ob es sich um einen Abfrageparameter handelt, der das JWT enthält (wenn ja, wird der Name des Abfrageparameters angegeben. Beachten Sie, dass Sie entweder "tokenHeader": "<token-header-name>" oder "tokenQueryParam": "<token-query-param-name>"> angeben können, aber nicht beides.
      • <tokenAuthScheme> ist der Name des Authentifizierungsschemas, das verwendet werden soll, wenn das JWT in einem Anforderungsheader enthalten ist. Beispiel: "Bearer".
      • <intended-audience> ist ein Wert, der im Zielgruppenclaim (aud) eines JWT zur Identifikation des beabsichtigten Empfängers des Tokens zulässig ist. Beispiel: Die Zielgruppe kann (muss aber nicht) dem Hostnamen des API-Gateways entsprechen. Sie können eine oder mehrere Zielgruppen angeben (maximal fünf). Informationen hierzu finden Sie unter Identitätsproviderdetails für iss- und aud-Claims sowie für die JWKS-URI.
      • "type": <"REMOTE_JWKS"|"STATIC_KEYS"> gibt an, wie das API-Gateway JWTs mit öffentlichen Prüfschlüsseln validieren soll. Geben Sie REMOTE_JWKS an, um das API-Gateway so zu konfigurieren, dass bis zu zehn öffentliche Prüfschlüssel zur Laufzeit vom Identitätsprovider abgerufen werden. Geben Sie STATIC_KEYS an, um das API-Gateway mit bis zu zehn öffentlichen Prüfschlüsseln zu konfigurieren, die bereits von einem Identitätsprovider ausgestellt wurden. (So kann das API-Gateway JWTs lokal verifizieren, ohne den Identitätsprovider kontaktieren zu müssen.)

      • <public-key-config> stellt die Details der JWT-Validierung je nachdem, ob Sie "REMOTE_JWKS" oder "STATIC_KEYS" als Wert von "type": angegeben haben, wie folgt bereit:

        • Wenn Sie "type": "REMOTE_JWKS" angegeben haben, um das API-Gateway für die Validierung von JWTs durch das Abrufen öffentlicher Prüfschlüssel vom Identitätsprovider zur Laufzeit zu konfigurieren, geben Sie folgende Details an:

                "publicKeys": {
                  "type": "REMOTE_JWKS",
                  "uri": "<uri-for-jwks>",
                  "maxCacheDurationInHours": <cache-time>,
                  "isSslVerifyDisabled": <true|false>
                }
          

          Dabei gilt:

          • "uri": "<uri-for-jwks>" gibt die URI an, von der das JSON Web Key Set (JWKS) abgerufen werden soll, mit dem die Signatur der JWTs verifiziert werden soll. Weitere Informationen über die anzugebende URI finden Sie unter Identitätsproviderdetails für iss- und aud-Claims sowie für die JWKS-URI. Beachten Sie dabei Folgendes:
            • Die URI muss aus dem Subnetz mit dem API-Gateway geroutet werden können, in dem die API bereitgestellt wird.
            • Wenn das API-Gateway das JWKS nicht abrufen kann, geben alle Anforderungen an das API-Deployment einen HTTP 500-Antwortcode zurück. Weitere Informationen zum Fehler finden Sie im Ausführungslog des API-Gateways (siehe Logging zu API-Deployments hinzufügen).
            • Bestimmte Schlüsselparameter müssen im JWKS vorhanden sein, um die JWT-Signatur zu verifizieren (siehe Erforderliche Schlüsselparameter zum Überprüfen von JWT-Signaturen).
            • Das JWKS kann bis zu zehn Schlüssel enthalten.
          • "maxCacheDurationInHours": <cache-time> gibt an, wie viele Stunden (zwischen 1 und 24) lang das API-Gateway das JWKS nach dem Abrufen cachen soll.
          • "isSslVerifyDisabled": <true|false> gibt an, ob die SSL-Überprüfung bei der Kommunikation mit dem Identitätsprovider deaktiviert werden soll. Oracle empfiehlt, diese Option nicht auf true zu setzen, weil sie die JWT-Validierung kompromittieren kann. API Gateway vertraut den Zertifikaten von mehreren Zertifizierungsstellen, die für OCI IAM mit Identitätsdomains, Oracle Identity Cloud Service (IDCS), Auth0 und Okta ausgestellt werden.

          Beispiel:

                "publicKeys": {
                  "type": "REMOTE_JWKS",
                  "uri": "https://www.somejwksprovider.com/oauth2/v3/certs",
                  "maxCacheDurationInHours": 3,
                  "isSslVerifyDisabled": false
                }
          

        • Wenn Sie "type": "STATIC_KEYS" angegeben haben, hängen die anzugebenden Details vom Format des Schlüssels ab, der bereits vom Identitätsprovider ausgestellt wurde (unabhängig vom Format können Sie bis zu zehn Schlüssel angeben):

          • Wenn es sich bei dem statischen Schlüssel um einen JSON Web Key handelt, geben Sie "format": "JSON_WEB_KEY" an, geben Sie die ID des statischen Schlüssels zum Signieren des JWT als Wert des "kid"-Parameters an, und geben Sie Werte für weitere Parameter zur Überprüfung der JWT-Signatur an.

            Beispiel:

                            
                  "publicKeys": {
                    "type": "STATIC_KEYS",
                    "keys": [
                      {
                        "format": "JSON_WEB_KEY",
                        "kid": "master_key",
                        "kty": "RSA",
                        "n": "0vx7agoebGc...KnqDKgw",
                        "e": "AQAB",
                        "alg": "RS256",
                        "use": "sig"
                      }
                    ]

            Beachten Sie, dass bestimmte Parameter im statischen Schlüssel vorhanden sein müssen, um die JWT-Signatur zu verifizieren (siehe Erforderliche Schlüsselparameter zum Überprüfen von JWT-Signaturen). Beachten Sie auch, dass RSA derzeit der einzige unterstützte Schlüsseltyp (kty) ist.

          • Wenn es sich bei dem statischen Schlüssel um einen PEM-codierten Public Key handelt, geben Sie "format": "PEM" an, geben Sie die ID des statischen Schlüssels zum Signieren des JWT als Wert von "kid" an, und geben Sie den Schlüssel als Wert von "key" an.

            Beispiel:

                            
                  "publicKeys": {
                    "type": "STATIC_KEYS",
                    "keys": [
                      {
                        "format": "PEM",
                        "kid": "master_key"
                        "key": -----BEGIN PUBLIC KEY-----XsEiCeYgglwW/KAhSSNRVdD60QlXYMWHOhXzSFDZCLf1WXxKMZCiMvVrsBIzmFEXnFmcsO2mxwlL5/8qQudomoP+yycJ2gWPIgqsZcQRheJWxVC5ep0MeEHlvLnEvCi9utpAnjrsZCQ7plfZVPX7XORvezwqQhBfYzwA27M2FgOOs8DOIYfqQ1Ki3DMqEppFnjLcjgQtknbTlT7YgG6tzobwig8M2KIrPjJ0BmbJAFH-----END PUBLIC KEY-----
                      }
                    ]

            Beachten Sie, dass die Marker -----BEGIN PUBLIC KEY----- und -----END PUBLIC KEY----- erforderlich sind.

      • verifyClaims gibt optional zusätzliche Claimnamen und -werte für einen oder mehrere zusätzliche Claims zur Überprüfung in einem JWT an (maximal zehn).
        • "key": "<claim-name>" ist der Name eines Claims, der in einem JWT enthalten sein kann oder muss. Der angegebene Claimname kann ein reservierter Claimname sein, wie der Subject-Claim (sub), oder ein benutzerdefinierter Claimname, der von einem bestimmten Identitätsprovider ausgestellt wird.
        • "values": ["<acceptable-value>", "<acceptable-value>"] (optional) gibt einen oder mehrere zulässige Werte für den Claim an.
        • "isRequired": <true|false> gibt an, ob der Claim im JWT enthalten sein muss.

        Beachten Sie, dass alle eingegebenen Schlüsselnamen und -werte einfach wie Zeichenfolgen behandelt werden und exakt mit den Namen und Werten im JWT übereinstimmen müssen. Das Abgleichen von Mustern und andere Datentypen werden nicht unterstützt.

      • maxClockSkewInSeconds: <seconds-difference> gibt optional den maximalen Zeitunterschied zwischen den Systemuhren des Identitätsproviders, der ein JWT ausgestellt hat, und dem API-Gateway an. Der angegebene Wert wird berücksichtigt, wenn das API-Gateway das JWT validiert, um zu bestimmen, ob es noch gültig ist. Verwenden Sie dazu den Claim "nicht vor" (nbf, falls vorhanden) und den Ablaufclaim (exp) im JWT. Der Mindestwert (und Standardwert) ist 0, der Höchstwert ist 120.

      Beispiel: Die folgende authentication-Policy konfiguriert das API-Gateway mit einem öffentlichen Verifizierungsschlüssel, der bereits von einem Identitätsprovider ausgegeben wurde, um das JWT im Autorisierungsanforderungsheader zu validieren:

      {
        "requestPolicies": {
          "authentication": {
            "type": "JWT_AUTHENTICATION",
            "isAnonymousAccessAllowed": false,
            "issuers": ["https://identity.oraclecloud.com/"],
            "tokenHeader": "Authorization",
            "tokenAuthScheme": "Bearer",
            "audiences": ["api.dev.io"],
            "publicKeys": {
              "type": "STATIC_KEYS",
              "keys": [
                {
                  "format": "JSON_WEB_KEY",
                  "kid": "master_key",
                  "kty": "RSA",
                  "n": "0vx7agoebGc...KnqDKgw",
                  "e": "AQAB",
                  "alg": "RS256",
                  "use": "sig"
                }
              ]
            },
            "verifyClaims": [
              {
                "key": "is_admin",
                "values": ["service:app", "read:hello"],
                "isRequired": true
              }
            ],
            "maxClockSkewInSeconds": 10
          }
        },
        "routes": [
          {
            "path": "/hello",
            "methods": ["GET"],
            "backend": {
              "type": "ORACLE_FUNCTIONS_BACKEND",
              "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
            }
          }
        ]
      }

2. Fügen Sie eine authorization-Anforderungs-Policy für jede Route in der API-Deployment-Spezifikation hinzu:

   1. Fügen Sie, falls noch nicht vorhanden, einen requestPolicies-Abschnitt nach dem backend-Abschnitt der ersten Route ein. Beispiel:

      {
        "requestPolicies": {
          "authentication": {
            "type": "JWT_AUTHENTICATION",
            "isAnonymousAccessAllowed": false,
            "issuers": ["https://identity.oraclecloud.com/"],
            "tokenHeader": "Authorization",
            "tokenAuthScheme": "Bearer",
            "audiences": ["api.dev.io"],
            "publicKeys": {
              "type": "STATIC_KEYS",
              "keys": [
                {
                  "format": "JSON_WEB_KEY",
                  "kid": "master_key",
                  "kty": "RSA",
                  "n": "0vx7agoebGc...KnqDKgw",
                  "e": "AQAB",
                  "alg": "RS256",
                  "use": "sig"
                }
              ]
            },
            "verifyClaims": [
              {
                "key": "is_admin",
                "values": ["service:app", "read:hello"],
                "isRequired": true
              }
            ],
            "maxClockSkewInSeconds": 10
          }
        },
        "routes": [
          {
            "path": "/hello",
            "methods": ["GET"],
            "backend": {
               "type": "ORACLE_FUNCTIONS_BACKEND",
               "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
            },
            "requestPolicies": {}
          }
        ]
      }

   2. Fügen Sie die folgende authorization-Policy zum requestPolicies-Abschnitt hinzu:

      {
        "requestPolicies": {
          "authentication": {
            "type": "JWT_AUTHENTICATION",
            "isAnonymousAccessAllowed": false,
            "issuers": ["https://identity.oraclecloud.com/"],
            "tokenHeader": "Authorization",
            "tokenAuthScheme": "Bearer",
            "audiences": ["api.dev.io"],
            "publicKeys": {
              "type": "STATIC_KEYS",
              "keys": [
                {
                  "format": "JSON_WEB_KEY",
                  "kid": "master_key",
                  "kty": "RSA",
                  "n": "0vx7agoebGc...KnqDKgw",
                  "e": "AQAB",
                  "alg": "RS256",
                  "use": "sig"
                }
              ]
            },
            "verifyClaims": [
              {
                "key": "is_admin",
                "values": ["service:app", "read:hello"],
                "isRequired": true
              }
            ],
            "maxClockSkewInSeconds": 10
          }
        },
        "routes": [
          {
            "path": "/hello",
            "methods": ["GET"],
            "backend": {
              "type": "ORACLE_FUNCTIONS_BACKEND",
              "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
            },
            "requestPolicies": {
              "authorization": {
                "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS">, 
                "allowedScope": [ "<scope>" ]
              }
            }
          }
        ]
      }

      Dabei gilt:

      • "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS"> gibt an, wie Zugriff auf die Route erteilt werden soll:

        • "AUTHENTICATION_ONLY": Zugriff wird nur Endbenutzern erteilt, die erfolgreich authentifiziert wurden. In diesem Fall zeigt die "isAnonymousAccessAllowed"-Eigenschaft in der authentication-Policy der API-Deployment-Spezifikation keine Wirkung.
        • "ANY_OF": Zugriff wird nur Endbenutzern erteilt, die erfolgreich authentifiziert wurden, sofern der scope-Claim des JWT einen der Zugriffsgeltungsbereiche enthält, die Sie in der Eigenschaft allowedScope angeben. In diesem Fall zeigt die "isAnonymousAccessAllowed"-Eigenschaft in der authentication-Policy der API-Deployment-Spezifikation keine Wirkung.
        • "ANONYMOUS": Zugriff wird allen Endbenutzern erteilt, selbst wenn diese nicht erfolgreich authentifiziert wurden. In diesem Fall müssen Sie die "isAnonymousAccessAllowed"-Eigenschaft in der authentication-Policy der API-Deployment-Spezifikation explizit auf true setzen.
      • "allowedScope": [ "<scope>" ] ist eine kommagetrennte Liste mit mindestens einer Zeichenfolge, die einem im scope-Claim des JWT enthaltenen Zugriffsgeltungsbereich entspricht. In diesem Fall müssen Sie die type-Eigenschaft auf "ANY_OF" setzen (die "allowedScope"-Eigenschaft wird ignoriert, wenn die type-Eigenschaft auf "AUTHENTICATION_ONLY" oder "ANONYMOUS" gesetzt wurde). Wenn Sie mehr als einen Geltungsbereich angeben, wird der Zugriff auf die Route erteilt, sobald einer der angegebenen Geltungsbereiche im scope-Claim des JWT enthalten ist.

      Beispiel: Die folgende Anforderungs-Policy definiert eine /hello-Route, die nur authentifizierten Endbenutzern mit dem Geltungsbereich read:hello Zugriff gewährt:

      {
        "requestPolicies": {
          "authentication": {
            "type": "JWT_AUTHENTICATION",
            "isAnonymousAccessAllowed": false,
            "issuers": ["https://identity.oraclecloud.com/"],
            "tokenHeader": "Authorization",
            "tokenAuthScheme": "Bearer",
            "audiences": ["api.dev.io"],
            "publicKeys": {
              "type": "STATIC_KEYS",
              "keys": [
                {
                  "format": "JSON_WEB_KEY",
                  "kid": "master_key",
                  "kty": "RSA",
                  "n": "0vx7agoebGc...KnqDKgw",
                  "e": "AQAB",
                  "alg": "RS256",
                  "use": "sig"
                }
              ]
            },
            "verifyClaims": [
              {
                "key": "is_admin",
                "values": ["service:app", "read:hello"],
                "isRequired": true
              }
            ],
            "maxClockSkewInSeconds": 10
          }
        },
        "routes": [
          {
            "path": "/hello",
            "methods": ["GET"],
            "backend": {
              "type": "ORACLE_FUNCTIONS_BACKEND",
              "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
            },
            "requestPolicies": {
              "authorization": {
                "type": "ANY_OF",
                "allowedScope": [ "read:hello" ]
              }
            }
          }
        ]
      }

   3. Fügen Sie eine authorization-Anforderungs-Policy für alle restlichen Routen in der API-Deployment-Spezifikation hinzu.
   Hinweis
   
   

   Wenn Sie keine authorization-Policy für eine bestimmte Route angeben, wird der Zugriff basierend auf der Annahme erteilt, dass eine solche Policy vorhanden ist, und die type-Eigenschaft wird auf "AUTHENTICATION_ONLY" gesetzt. Anders ausgedrückt: Ungeachtet der Einstellung der isAnonymousAccessAllowed-Eigenschaft in der authentication-Policy der API-Deployment-Spezifikation können:

   • nur authentifizierte Endbenutzer auf die Route zugreifen
   • alle authentifizierten Endbenutzer unabhängig von den Zugriffsgeltungsbereichen im scope-Claim des JWT auf die Route zugreifen
   • anonyme Endbenutzer nicht auf die Route zugreifen
3. Speichern Sie die JSON-Datei, die die API-Deployment-Spezifikation enthält.

4. Verwenden Sie die API-Deployment-Spezifikation, wenn Sie ein API-Deployment wie folgt erstellen oder aktualisieren:

   • Durch Angabe der JSON-Datei in der Konsole bei Auswahl der Option Vorhandene API hochladen
   • Durch Angabe der JSON-Datei in einer Anforderung an die REST-API von API-Gateway

   Weitere Informationen finden Sie unter API durch das Erstellen eines API-Deployment in einem API-Gateway bereitstellen und API-Gateway aktualisieren.

5. (Optional) Bestätigen Sie, dass die API erfolgreich bereitgestellt wurde, indem Sie sie aufrufen (siehe In einem API-Gateway bereitgestellte API aufrufen).