Oracle Cloud Infrastructure - Dokumentation

Authentifizierungs- und Autorisierungsanforderungs-Policys mit der Konsole hinzufügen

Mit der Konsole Authentifizierungsanforderungs-Policys und Autorisierungsanforderungs-Policys zu einer API-Deployment-Spezifikation hinzufügen.

  1. Erstellung oder Aktualisierung eines API-Deployments mit der Konsole, wählen Sie die Option Deployment erstellen aus, und geben Sie auf der Seite Basisinformationen Details ein.

    Weitere Informationen finden Sie unter API durch das Erstellen eines API-Deployments in einem API-Gateway implementieren und API-Gateways aktualisieren.

  2. Wählen Sie Weiter, 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 mehrere Authentifizierungsserver verwenden möchten, wählen Sie alternativ Multi-Authentifizierung aus, und befolgen Sie die Anweisungen unter Mehrere Authentifizierungsserver zu demselben API-Deployment mit der Konsole hinzufügen.

  4. Wählen Sie Anonymen Zugang aktivieren aus, oder heben Sie die Auswahl auf, um anzugeben, ob nicht authentifizierte (d.h. anonyme) Endnutzer auf Routen im API-Deployment zugreifen dürfen.

    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 Tokenauthentifizierung aus, und geben Sie Folgendes an:
    • Tokenverzeichnis: Gibt an, ob Token in einem Anforderungsheader oder einem Abfrageparameter enthalten sind.

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

      • Token-Headername: und Authentifizierungsschema: Wenn Token in einem Anforderungsheader enthalten sind, geben Sie den Namen des Headers (Beispiel: Authorization) und das HTTP-Authentifizierungsschema ein (derzeit wird nur Bearer unterstützt).
      • Tokenparametername: Wenn Token in einem Abfrageparameter enthalten sind, geben Sie den Namen des Abfrageparameters ein
  6. Geben Sie ein, 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 aus einem Vault im Vault-Service abgerufenen Client-Secrets) 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 Clientanwendung beim Autorisierungsserver erstellen und registrieren. Beispiel: 5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1. Siehe Voraussetzungen für die Tokenauthentifizierung.
      • Vault: Der Name eines Vaults im Vault-Service, der das Client Secret enthält, das aus der Liste der Vaults im angegebenen Compartment 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 aus der Liste der Vault Secrets im angegebenen Compartment an den Introspektionsendpunkt gesendet werden soll.
      • Vault Secret-Versionsnummer: Die Version des Vault Secrets, das das Client Secret enthält, 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) zwischen dem API-Gateway, um die Antwort vom Introspektionsendpunkt zu cachen.
      • Max. Taktverschiebung in Sekunden: (Optional) Die maximale Zeitdifferenz zwischen den Systemtakten des Autorisierungsservers, der ein Token ausgegeben 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 hierzu 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-Überprüfungen deaktivieren: Gibt an, ob die SSL-Überprüfung bei die 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 beeinträchtigen kann. API Gateway vertraut 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 Remote-JWCS aus der Liste Typ aus, und geben Sie folgende Informationen an:

      • JWKS-URI: Die URI, von der das JSON Web Key Set (JWKS) abgerufen wird, mit dem die Signatur der JWTs verifiziert werden kann. 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 routbar sein, 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).
        • Der JWKS kann bis zu zehn Schlüssel enthalten.
      • Maximale Cachedauer in Stunden: Die Anzahl der Stunden (zwischen 1 und 24) lang das API-Gateway das JWKS-Satz nach den Abrufen cache.
      • Max. Taktverschiebung in Sekunden: (Optional) Die maximale Zeitdifferenz zwischen den Systemtakten des Autorisierungsservers, der ein Token ausgegeben hat, und dem API-Gateway. Der hier eingegebene Wert wird berücksichtigt, wenn das API-Gateway das JWT validiert, um zu bestimmen, ob es noch gültig ist. Verwenden Sie hierzu 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-Verifizierung deaktivieren: Gibt an, ob die SSL-Überprüfung beim Kommunizieren mit dem Identitätsprovider deaktiviert werden muss. 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 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 (sodass das API-Gateway JWTs lokal verifizieren kann, ohne dass der Identitätsprovider kontaktiert werden müsste), wählen Sie in die Liste Typ den Eintrag "Statische Tasten" 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-Webschlüssel oder als PEM-codierter Public Key.

        • JSON-Webschlüssel: Wenn der statische Schlüssel ein JSON-Webschlüssel ist, fügen Sie den Schlüssel in dieses Feld hinzu.

          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-codierter Public Key: Wenn der statische Schlüssel ein PEM-codierter Public Key ist, fügen Sie den Schlüssel in dieses Feld hinzu. 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 (maximal zehn).
  7. (Optional) Geben Sie zusätzliche Details für die 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 ein, die im Ausstellerclaim (iss) eines JWTs für den Zugriff auf das API-Deployment zulässig ist. Beispiel: Um ein von OCI IAM ausgestelltes JWT mit Identitätsdomains für den Zugriff auf die API-Bereitstellung zu aktivieren, 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 (maximal 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 Zielgruppe: 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 (maximal fünf).

    3. Claims validation: (Optional) Zusätzlich zu den bereits angegebenen Werten für die Zielgruppenclaim (aud) und die Ausstellerclaim (iss) können Sie Namen und Werte für einen oder mehrere zusätzliche Claims angeben, die in einem JWT validiert werden sollen. 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 Anspruch ist 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, zurückgegeben), 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), wählen Sie Standard (HTTP 401 nicht autorisiert) aus.

    2. Wenn das API-Gateway einen OpenID Connect-Autorisierungsablauf zum Abrufen eines neuen JWT-Zugriffstokens verwenden soll, wählen Sie OAuth 2.0 aus. Beachten Sie, dass diese Option nur verfügbar ist, wenn Sie zuvor in der Liste Validierungstyp die Option OAuth 2.0-Introspektionsendpunkt ausgewählt haben. Wählen Sie eine der folgenden Optionen aus:

      • Bereiche: Mindestens ein Zugriffsgeltungsbereich, der in einen scope-Claim aufgenommen werden soll, der an den Autorisierungsserver gesendet wird. Um den OpenID Connect-Autorisierungsablauf verwenden zu können, müssen Sie openid als einen der Geltungsbereiche aufnehmen. Beispiel: openid, email:read, profile.
      • Antworttyp: Der Typ der Antwort, die für den Autorisierungsablauf erforderlich ist. 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 Pfad übereinstimmen, der für das Abmelde-Backend definiert ist. Beispiel: /revoke

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

      • Antwortablauf in Stunden: (optional) Die Zeitdauer für das Zwischenspeichern des vom Autorisierungsablauf generierten JWT-Tokens. Der Standardwert beträgt 1 Stunde.
      • Clientzugangsdaten für OAuth2-Introspektionsendpunkt 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). 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: Der Name eines Vaults im Vault-Service, der das Client Secret enthält, das aus der Liste der Vaults im angegebenen Compartment an den Introspektionsendpunkt gesendet werden soll.
        • Vault Secret: Der Name des Vault Secrets mit dem Client Secret, das an den Introspektionsendpunkt gesendet werden soll, aus der Liste der Vault Secrets im angegebenen Compartment. .
        • Vault Secret-Versionsnummer: Die Version des Vault Secrets, das das Client Secret enthält, das an den Introspektionsendpunkt gesendet werden soll.

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

      • 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, um CSRF (Cross-Site Request Forgery) und Autorisierungscode-Injection-Angriffe zu verhindern. PKCE ist kein Ersatz für ein Client Secret, und PKCE wird empfohlen, auch wenn ein Client Secret verwendet wird. Weitere Informationen zu PKCE finden Sie in der Dokumentation zu OAuth 2.0.
      • 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 aus, 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 in einem X-CSRF-TOKEN-Anforderungsheader enthalten, zusätzlich zum JWT-TOKEN im Sessioncookie, das automatisch enthalten ist.
        • 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 Cross-Site Request Forgery-(CSRF-)Schutz

      • Cookies für Zwischenschritte verwenden: (optional) Geben Sie an, wie Zwischenschrittwerte für den Autorisierungsablauf 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.
    3. Wenn Sie die Antwort an 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, um zum API-Client zurückzukehren:
      • 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 (mit Ausnahme von 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 für einzelne Routen im API-Deployment auf der Seite Routen einzugeben.

  10. Wählen Sie Route hinzufügen aus, und geben Sie die erste Route im API-Deployment ein, 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 gemäß der eingegebenen Kontextvariablen und Regeln an andere 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 andere Backends verwenden möchten, wählen Sie alternativ 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: Der Typ des Backend-Service. Folgende Optionen sind verfügbar:

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

    • 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 Zugang 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 Zugang 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 Zugang 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: Ungeachten der Einstellung der Option Anonymen Zugang aktivieren der Authentifizierungs-Policy:

    • 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 Erstellen, Weiter aus, um die Details zu prüfen, die Sie für das API-Deployment eingegeben haben.
  13. Wählen Sie Erstellen oder Aktualisieren aus, um das API-Deployment zu erstellen oder aktualisiert zu werden.
  14. (Optional) Bestätigen Sie, dass die API erfolgreich bereitgestellt wurde, indem Sie sie aufrufen (siehe In einem API-Gateway bereitgestellte API aufrufen).