Documentazione dell'infrastruttura Oracle Cloud

Utilizzo di un criterio di richiesta di autenticazione JWT_AUTHENTICATION (non più consigliato)

Quando si utilizza un criterio di richiesta di autenticazione di tipo JWT_AUTHENTICATION, prima che un utente finale possa accedere a una distribuzione API che utilizza i token Web JSON (JWT) per l'autenticazione e l'autorizzazione, deve ottenere un JWT da un provider di identità.

Nota

Nelle release precedenti, è possibile che siano stati creati criteri di richiesta di autenticazione di tipo JWT_AUTHENTICATION per utilizzare i JWT per l'autenticazione.

Se si stanno creando nuovi criteri di richiesta di autenticazione per utilizzare JWT, ora si consiglia di creare criteri di richiesta di autenticazione di tipo TOKEN_AUTHENTICATION (vedere Uso della console per aggiungere criteri di richiesta di autenticazione e autorizzazione token e Modifica di un file JSON per aggiungere criteri di richiesta di autenticazione e autorizzazione token). Si consiglia inoltre di eseguire la migrazione dei criteri di richiesta JWT_AUTHENTICATION esistenti ai criteri TOKEN_AUTHENTICATION.

Tenere presente che i criteri di richiesta JWT_AUTHENTICATION esistenti sono ancora supportati. Si noti inoltre che, sebbene sia possibile creare nuovi criteri di richiesta JWT_AUTHENTICATION definendo la specifica di distribuzione API in un file JSON (come descritto nelle istruzioni originali in questa sezione), si consiglia di creare criteri di richiesta di autenticazione di tipo TOKEN_AUTHENTICATION.

Quando si chiama un'API distribuita su un gateway API, il client API fornisce il JWT come parametro di query o nell'intestazione della richiesta. Il gateway API convalida il JWT utilizzando una chiave di verifica pubblica corrispondente fornita dal provider di identità emittente. Utilizzando il criterio di richiesta di autenticazione JWT_AUTHENTICATION della distribuzione API, è possibile configurare il modo in cui il gateway API convalida i JWT:

  • È possibile configurare il gateway API per recuperare le chiavi di verifica pubbliche dal provider di identità in fase di esecuzione. In questo caso, il provider di identità funge da server di autorizzazione.
  • Puoi configurare il gateway API in anticipo con chiavi di verifica pubbliche già emesse da un provider di identità (indicate come 'chiavi statiche'), consentendo al gateway API di verificare i JWT in locale in fase di esecuzione senza dover contattare il provider di identità. Il risultato è una convalida del token più rapida.

Per aggiungere un nuovo criterio di richiesta di autenticazione e autorizzazione JWT_AUTHENTICATION a una specifica di distribuzione API in un file JSON, procedere come segue.

  1. Aggiungere un criterio di richiesta authentication che si applichi a tutti gli instradamenti nella specifica di distribuzione API:

    1. Inserire una sezione requestPolicies prima della sezione routes, se non esiste già. Ad esempio:

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

    2. Aggiungere il seguente criterio authentication alla nuova sezione requestPolicies. 

      {
  "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"
      }
    }
  ]
}

      dove:

      • "isAnonymousAccessAllowed": <true|false> indica facoltativamente se gli utenti finali non autenticati (ovvero anonimi) possono accedere agli instradamenti nella specifica di distribuzione API. Se non si desidera che gli utenti finali anonimi possano accedere agli instradamenti, impostare questa proprietà su false. Se non si include questa proprietà nel criterio authentication, viene utilizzato il valore predefinito false. Tenere presente che se si include questa proprietà e la si imposta su true, è inoltre necessario specificare in modo esplicito ogni instradamento a cui è consentito l'accesso anonimo impostando la proprietà type su "ANONYMOUS" nel criterio authorization di ciascun instradamento.
      • <issuer-url> è l'URL (o una stringa di testo) per un provider di identità che è consentito nella richiesta dell'emittente (iss) di un JWT da utilizzare per accedere alla distribuzione dell'API. Ad esempio, per abilitare un JWT emesso da IAM OCI con domini di Identity da utilizzare per accedere alla distribuzione API, immettere https://identity.oraclecloud.com/ . È possibile specificare uno o più provider di identità (fino a un massimo di cinque). Vedere Dettagli provider di identità da utilizzare per l'emissione e l'audit delle richieste e per l'URI JWKS.
      • <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>"> indica se si tratta di un'intestazione di richiesta che contiene il JWT (e, in tal caso, il nome dell'intestazione) o di un parametro di query che contiene il JWT (e, in tal caso, il nome del parametro di query). Si noti che è possibile specificare "tokenHeader": "<token-header-name>" o "tokenQueryParam": "<token-query-param-name>">, ma non entrambi.
      • <tokenAuthScheme> è il nome dello schema di autenticazione da utilizzare se il file JWT è contenuto in un'intestazione di richiesta. Ad esempio, "Bearer".
      • <intended-audience> è un valore consentito nella richiesta dell'audience (aud) di un JWT per identificare il destinatario previsto del token. Ad esempio, il pubblico potrebbe essere, ma non necessariamente, il nome host del gateway API. È possibile specificare uno o più audience (fino a un massimo di cinque). Vedere Dettagli provider di identità da utilizzare per l'emissione e l'audit delle richieste e per l'URI JWKS.
      • "type": <"REMOTE_JWKS"|"STATIC_KEYS"> indica la modalità con cui si desidera che il gateway API convalida JWT utilizzando chiavi di verifica pubbliche. Specificare REMOTE_JWKS per configurare il gateway API per recuperare fino a dieci chiavi di verifica pubbliche dal provider di identità in fase di esecuzione. Specificare STATIC_KEYS per configurare il gateway API con un massimo di dieci chiavi di verifica pubbliche già emesse da un provider di identità (abilitando il gateway API per verificare i JWT in locale senza dover contattare il provider di identità).

      • <public-key-config> fornisce i dettagli della convalida JWT, a seconda che sia stato specificato "REMOTE_JWKS" o "STATIC_KEYS" come valore di "type": come segue:

        • Se è stato specificato "type": "REMOTE_JWKS" per configurare il gateway API per convalidare i JWT recuperando le chiavi di verifica pubbliche dal provider di identità in fase di esecuzione, fornire i dettagli riportati di seguito.

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

          dove:

          • "uri": "<uri-for-jwks>" specifica l'URI da cui recuperare il set di chiavi Web JSON (JWKS) da utilizzare per verificare la firma sui JWT. Per ulteriori informazioni sull'URI da specificare, vedere Dettagli provider di identità da utilizzare per l'emissione e l'audit delle richieste e per l'URI JWKS. Tenere presente quanto riportato di seguito.
            • L'URI deve essere instradabile dalla subnet contenente il gateway API su cui viene distribuita l'API.
            • Se il gateway API non riesce a recuperare JWKS, tutte le richieste alla distribuzione API restituiranno un codice di risposta HTTP 500. Per ulteriori informazioni sull'errore, fare riferimento al log di esecuzione del gateway API (vedere Aggiunta di log alle distribuzioni API).
            • Alcuni parametri chiave devono essere presenti in JWKS per verificare la firma di JWT (vedere Parametri chiave necessari per verificare le firme JWT).
            • Il JWKS può contenere fino a dieci chiavi.
          • "maxCacheDurationInHours": <cache-time> specifica il numero di ore (tra 1 e 24) in cui il gateway API deve inserire nella cache JWKS dopo il recupero.
          • "isSslVerifyDisabled": <true|false> indica se disabilitare la verifica SSL durante la comunicazione con il provider di identità. Oracle consiglia di non impostare questa opzione su true perché può compromettere la convalida JWT. Il gateway API considera sicuri i certificati di più autorità di certificazione emesse per IAM OCI con domini di Identity, Oracle Identity Cloud Service (IDCS), Auth0 e Okta.

          Ad esempio:

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

        • Se è stato specificato "type": "STATIC_KEYS", i dettagli da fornire dipendono dal formato della chiave già emessa dal provider di identità (indipendentemente dal formato, è possibile specificare fino a dieci chiavi):

          • Se la chiave statica è una chiave Web JSON, specificare "format": "JSON_WEB_KEY", specificare l'identificativo della chiave statica utilizzata per firmare il JWT come valore del parametro "kid" e fornire i valori per altri parametri per verificare la firma del JWT.

            Ad esempio:

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

            Si noti che alcuni parametri devono essere presenti nella chiave statica per verificare la firma di JWT (vedere Parametri chiave necessari per verificare le firme JWT). Si noti inoltre che RSA è attualmente l'unico tipo di chiave supportato (kty).

          • Se la chiave statica è una chiave pubblica con codifica PEM, specificare "format": "PEM", specificare l'identificativo della chiave statica utilizzata per firmare JWT come valore "kid" e fornire la chiave come valore "key".

            Ad esempio:

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

            Si noti che gli indicatori -----BEGIN PUBLIC KEY----- e -----END PUBLIC KEY----- sono obbligatori.

      • verifyClaims specifica facoltativamente nomi e valori aggiuntivi per una o più richieste di risarcimento aggiuntive da convalidare in un JWT (fino a un massimo di dieci).
        • "key": "<claim-name>" è il nome di una richiesta che può essere inclusa o deve essere inclusa in una dichiarazione congiunta. Il nome di richiesta specificato può essere un nome di richiesta riservato, ad esempio l'oggetto (sub) o un nome di richiesta personalizzato emesso da un determinato provider di identità.
        • "values": ["<acceptable-value>", "<acceptable-value>"] (facoltativo) indica uno o più valori accettabili per la richiesta.
        • "isRequired": <true|false> indica se la richiesta deve essere inclusa nel JWT.

        Si noti che i nomi e i valori delle chiavi immessi vengono semplicemente gestiti come stringhe e devono corrispondere esattamente ai nomi e ai valori nel JWT. Corrispondenza pattern e altri tipi di dati non supportati

      • maxClockSkewInSeconds: <seconds-difference> specifica facoltativamente la differenza di tempo massima tra i clock di sistema del provider di identità che ha emesso un JWT e il gateway API. Il valore specificato viene preso in considerazione quando il gateway API convalida il JWT per determinare se è ancora valido, utilizzando il claim non prima (nbf) (se presente) e il claim di scadenza (exp) nel JWT. Il valore minimo (e predefinito) è 0, il valore massimo è 120.

      Ad esempio, il seguente criterio authentication configura il gateway API con una chiave di verifica pubblica già emessa da un provider di identità per convalidare il JWT nell'intestazione della richiesta di autorizzazione:

      {
  "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. Aggiungere un criterio di richiesta authorization per ogni instradamento nella specifica di distribuzione API:

    1. Inserire una sezione requestPolicies dopo la sezione backend del primo instradamento, se non ne esiste già una. Ad esempio:

      {
  "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. Aggiungere il seguente criterio authorization alla sezione requestPolicies: 

      {
  "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>" ]
        }
      }
    }
  ]
}

      dove:

      • "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS"> indica come concedere l'accesso all'instradamento:

        • "AUTHENTICATION_ONLY": consente l'accesso solo agli utenti finali autenticati correttamente. In questo caso, la proprietà "isAnonymousAccessAllowed" nel criterio authentication della specifica di distribuzione API non ha alcun effetto.
        • "ANY_OF": consente l'accesso solo agli utenti finali autenticati correttamente, a condizione che la richiesta scope di JWT includa uno degli ambiti di accesso specificati nella proprietà allowedScope. In questo caso, la proprietà "isAnonymousAccessAllowed" nel criterio authentication della specifica di distribuzione API non ha alcun effetto.
        • "ANONYMOUS": concedere l'accesso a tutti gli utenti finali, anche se non sono stati autenticati correttamente. In questo caso, è necessario impostare in modo esplicito la proprietà "isAnonymousAccessAllowed" su true nel criterio authentication della specifica di distribuzione API.
      • "allowedScope": [ "<scope>" ] è una lista delimitata da virgole di una o più stringhe che corrispondono agli ambiti di accesso inclusi nella richiesta scope di JWT. In questo caso, è necessario impostare la proprietà type su "ANY_OF" (la proprietà "allowedScope" viene ignorata se la proprietà type è impostata su "AUTHENTICATION_ONLY" o "ANONYMOUS"). Si noti inoltre che se si specificano più ambiti, l'accesso all'instradamento viene concesso se uno qualsiasi degli ambiti specificati è incluso nella richiesta scope di JWT.

      Ad esempio, il seguente criterio di richiesta definisce un instradamento /hello che consente l'accesso solo agli utenti finali autenticati con ambito read:hello:

      {
  "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. Aggiungere un criterio di richiesta authorization per tutti gli instradamenti rimanenti nella specifica di distribuzione API.
    Nota

    Se non si include un criterio authorization per un determinato instradamento, l'accesso viene concesso come se tale criterio esistesse e la proprietà type è impostata su "AUTHENTICATION_ONLY". In altre parole, indipendentemente dall'impostazione della proprietà isAnonymousAccessAllowed nel criterio authentication della specifica di distribuzione API:

    • solo gli utenti finali autenticati possono accedere al percorso
    • tutti gli utenti finali autenticati possono accedere all'instradamento indipendentemente dagli ambiti di accesso nella richiesta scope di JWT
    • gli utenti finali anonimi non possono accedere all'instradamento
  3. Salvare il file JSON contenente la specifica di distribuzione API.

  4. Utilizzare la specifica di distribuzione API quando si crea o si aggiorna una distribuzione API nei modi riportati di seguito.

    • specificando il file JSON nella console quando si seleziona l'opzione Carica un'API di distribuzione esistente
    • specificando il file JSON in una richiesta all'API REST del gateway API

    Per ulteriori informazioni, vedere Distribuzione di un'interfaccia API in un Gateway API mediante la creazione di una distribuzione API e Aggiornamento di un Gateway API.

  5. (Facoltativo) Confermare che l'interfaccia API è stata distribuita correttamente chiamandola (vedere Chiamata di un'interfaccia API distribuita su un gateway API).

Esempio: migrazione di un criterio di richiesta JWT_AUTHENTICATION a un criterio di richiesta TOKEN_AUTHENTICATION

Questa sezione mostra un esempio di criterio di richiesta JWT_AUTHENTICATION esistente migrato a un criterio TOKEN_AUTHENTICATION.

Un modo per affrontare la migrazione consiste nel creare un criterio di richiesta TOKEN_AUTHENTICATION vuoto, quindi inserirlo con i valori del criterio di richiesta JWT_AUTHENTICATION

Prima della migrazione:

Il criterio di richiesta JWT_AUTHENTICATION originale, prima della migrazione:

{
  "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" ]
        }
      }
    }
  ]
}

Dopo la migrazione:

Il nuovo criterio di richiesta TOKEN_AUTHENTICATION popolato con i valori del criterio di richiesta JWT_AUTHENTICATION originale:

{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "maxClockSkewInSeconds": 10,
      "validationPolicy": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ],
        "additionalValidationPolicy": {
          "audiences": [
            "api.dev.io"
          ],
          "verifyClaims": [
            {
              "key": "is_admin",
              "values": [
                "service:app",
                "read:hello"
              ],
              "isRequired": true
            }
          ],
          "issuers": [
            "https://identity.oraclecloud.com/"
          ]
        }
      }
    }
  },
  "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"
          ]
        }
      }
    }
  ]
}