Editando um Arquivo JSON para Adicionar Políticas da Solicitação de Autenticação e Autorização de Token

Adicione políticas de solicitação de autenticação e autorização a uma especificação da implantação da API em um arquivo JSON.

Usando seu editor de JSON preferido, edite a especificação de implantação de API existente à qual você deseja adicionar a funcionalidade de autenticação e autorização ou crie uma nova especificação de implantação de API (consulte Criando uma Especificação de Implantação de API).

No mínimo, a especificação de implantação de API incluirá uma seção routes contendo:
- Um caminho. Por exemplo, /hello
- Um ou mais métodos. Por exemplo, GET
- Uma definição de um back-end. Por exemplo, uma URL ou o OCID de uma função no OCI Functions.
Por exemplo, a seguinte especificação de implantação básica da API define uma função simples sem servidor do Hello World nas Funções do OCI como um back-end único:
```
{
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```

Insira uma seção requestPolicies antes da seção routes (se ainda não houver uma) para criar uma política de solicitação authentication que se aplique a todas as rotas na especificação de implantação de API. Por exemplo:


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

Adicione a política de solicitação authentication da seguinte forma
```
{
  "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"
      }
    }
  ]
}
```
em que:
- "authentication": {"type": "TOKEN_AUTHENTICATION"... especifica que você deseja usar tokens para autenticação.
- <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>"> indica se é um cabeçalho de solicitação que contém o token (e em caso afirmativo, o nome do cabeçalho) ou um parâmetro da consulta que contém o token (e em caso afirmativo, o nome do parâmetro da consulta). Observe que você pode especificar "tokenHeader": "<token-header-name>" ou "tokenQueryParam": "<token-query-param-name>">, mas não ambos. Por exemplo, "tokenHeader": "Authorization"
- <tokenAuthScheme> é o nome do esquema que será usado se o token estiver contido em um cabeçalho de solicitação. Por exemplo, "Bearer".
- "isAnonymousAccessAllowed": <true|false> indica opcionalmente se usuários finais não autenticados (ou seja, anônimos) podem acessar rotas na especificação de implantação de API. Se você nunca quiser que usuários finais anônimos possam acessar rotas, defina essa propriedade como false. Se você não incluir essa propriedade na política authentication, o padrão false será usado. Observe que, se você não incluir essa propriedade e defini-la como true, também precisará especificar explicitamente cada rota para a qual o acesso anônimo é permitido, definindo a propriedade type como "ANONYMOUS" na política authorization de cada rota.
- maxClockSkewInSeconds: <seconds-difference> opcionalmente especifica a diferença de tempo máxima entre os relógios do sistema do provedor de identidade que emitiu um JWT e o gateway de API. O valor que você especifica é levado em consideração quando o gateway da API valida o JWT para determinar se ele ainda é válido, usando a reivindicação não antes (nbf) (se presente) e a reivindicação de expiração (exp) no JWT. O mínimo (e padrão) é 0, o máximo é 120.
- "validationPolicy": {<validation-policy-config>} especifica uma política de validação para validar tokens, conforme descrito nas etapas a seguir.
Se você quiser que o gateway de API valide tokens JWT e tokens não JWT com um ponto final de introspecção do servidor de autorização do OAuth 2.0 usando credenciais do cliente (incluindo um segredo do cliente recuperado de um vault no serviço Vault), adicione a seguinte política de validação à seção validationPolicy vazia:
```
      "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>
          }]
        }
      }
```
em que:
- "validationPolicy": {"type": "REMOTE_DISCOVERY"...} especifica que você deseja validar tokens com um ponto final de introspecção do servidor de autorização do OAuth 2.0 usando credenciais do cliente (incluindo um segredo do cliente recuperado de um vault no serviço Vault).
- clientDetails": {"type": "CUSTOM"...} especifica os detalhes do segredo do cliente a ser recuperado de um vault no serviço Vault:
  - "clientId": "<client-id>" especifica o ID do cliente a ser enviado para o ponto final de introspecção. Você obtém um ID de cliente criando e registrando um aplicativo cliente com o servidor de autorização. Por exemplo, 5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1 . Consulte Pré-requisitos para Autenticação de Token.
  - "clientSecretId": "<secret-ocid>" especifica o OCID do segredo do vault que contém o segredo do cliente a ser enviado para o ponto final de introspecção. Por exemplo, ocid1.vaultsecret.oc1.iad.amaaaaaa______cggit3q
  - "clientSecretVersionNumber": <secret-version-number> especifica a versão do segredo do vault que contém o segredo do cliente a ser enviado para o ponto final de introspecção. Por exemplo, 1
- "uri": "<well-known-uri>" especifica o URL bem conhecido de um servidor de autorização do qual o gateway de API deve obter pontos finais de metadados de autorização. Por exemplo, https://my-idp/oauth2/default/.well-known/openid-configuration. Observe que o URL deve ser roteável da sub-rede contendo o gateway da API no qual a API está implantada.
- "isSslVerifyDisabled": <true|false> indica se a verificação de SSL deve ser desativada durante a comunicação com o servidor de autorização. A Oracle recomenda não definir essa opção para true porque ela pode equilibrar a validação de JWT. O API Gateway confia em certificados de várias Autoridades de Certificado emitidas para o OCI IAM com Domínios de Identidade, Oracle Identity Cloud Service (IDCS), Auth0 e Okta.
- "maxCacheDurationInHours": <cache-time> especifica o número de horas (entre 1 e 24) que o gateway de API deve colocar em cache a resposta do ponto final da introspecção.
- "additionalValidationPolicy": {"issuers": ...} especifica detalhes adicionais para validação de token:
  - <issuer-url> é o URL (ou uma sequência de caracteres de texto) de um servidor de autorização permitido na reivindicação do emissor (iss) de um JWT a ser usado para acessar a implantação da API. Por exemplo, para permitir que um JWT emitido pelo OCI IAM com Domínios de Identidade seja usado para acessar a implantação de API, especifique https://identity.oraclecloud.com/. Você pode especificar um ou vários servidores de autorização (até cinco no máximo). Consulte Detalhes do Provedor de Identidades a Serem Usados para Reivindicações iss e aud e para o URI JWKS.
  - <intended-audience> é um valor permitido na reivindicação de público-alvo (aud) de um JWT para identificar o destinatário pretendido do token. Por exemplo, o público-alvo pode ser, mas não precisa ser, o nome do host do gateway de API. Você pode especificar um ou vários públicos-alvo (até cinco no máximo). Consulte Detalhes do Provedor de Identidades a Serem Usados para Reivindicações iss e aud e para o URI JWKS.
  - "verifyClaims": {...} especifica opcionalmente nomes e valores de reivindicação adicionais para uma ou mais reivindicações adicionais a serem validadas em um JWT (até um máximo de dez):
    - "key": "<claim-name>" é o nome de uma reivindicação que pode ou deve ser incluída em um JWT. O nome da reivindicação que você especificar pode ser um nome reservado da reivindicação, como o assunto (sub) ou um nome personalizado emitido por um determinado servidor de autorização
    - "values": ["<acceptable-value>", "<acceptable-value>"] (opcionalmente) indica um ou mais valores aceitáveis para a reivindicação.
    - "isRequired": <true|false> indica se a reivindicação deve ser incluída no JWT.
    Observe que todos os nomes e valores de chave informados são simplesmente tratados como strings e devem corresponder exatamente a nomes e valores no JWT. Correspondência de padrões e outros tipos de dados não são suportados
Por exemplo, a seguinte política authentication configura o gateway de API para validar um token no cabeçalho da solicitação de Autorização usando credenciais do cliente (incluindo um segredo do cliente recuperado de um vault no serviço Vault) passado para um ponto final de introspecção do OAuth 2.0):
```
{
  "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"
      }
    }
  ]
}
```
Se você quiser que o gateway de API valide JWTs recuperando chaves de verificação públicas do provedor de identidades no runtime, adicione a seguinte política de validação à seção validationPolicy vazia:
```
      "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>
          }]
        }
      }
```
em que:
- "validationPolicy": {"type": "REMOTE_JWKS"... especifica que você deseja configurar o gateway de API para recuperar até dez chaves de verificação públicas do provedor de identidades no runtime.
- "uri": "<uri-for-jwks>" especifica o URI do qual será recuperado o JWKS (JSON Web Key Set) a ser usado para verificar a assinatura em JWTs. Para obter mais informações sobre o URI a ser especificado, consulte Detalhes do Provedor de Identidades a Serem Usados para Reivindicações iss e aud e para o URI JWKS. Observe o seguinte:
  - O URI deve ser roteável da sub-rede que contém o gateway de API no qual a API está implantada.
  - Se o gateway de API falhar ao recuperar o JWKS, todas as solicitações para a implantação de API retornarão um código de resposta HTTP 500. Consulte o log de execução do gateway de API para obter mais informações sobre o erro (consulte Adicionando Registro em Log a Implantações de API).
  - Determinados parâmetros de chave devem estar presentes no JWKS para verificar a assinatura do JWT (consulte Parâmetros de Chave Necessários para Verificar Assinaturas de JWT).
  - O JWKS pode conter até dez chaves.
- "isSslVerifyDisabled": <true|false> indica se a verificação SSL será desativada ao se comunicar com o provedor de identidades. A Oracle recomenda não definir essa opção para true porque ela pode equilibrar a validação de JWT. O API Gateway confia em certificados de várias Autoridades de Certificado emitidas para o OCI IAM com Domínios de Identidade, Oracle Identity Cloud Service (IDCS), Auth0 e Okta.
- "maxCacheDurationInHours": <cache-time> especifica o número de horas (entre 1 e 24) em que o gateway de API deve colocar em cache o JWKS após recuperá-lo.
- "additionalValidationPolicy": {"issuers": ...} especifica detalhes adicionais para validação de token:
  - <issuer-url> é o URL (ou uma sequência de caracteres de texto) de um provedor de identidades que é permitido na reivindicação do emissor (iss) de um JWT a ser usado para acessar a implantação da API. Por exemplo, para permitir que um JWT emitido pelo OCI IAM com Domínios de Identidade seja usado para acessar a implantação de API, informe https://identity.oraclecloud.com/ . Você pode especificar um ou vários provedores de identidade (até cinco no máximo). Consulte Detalhes do Provedor de Identidades a Serem Usados para Reivindicações iss e aud e para o URI JWKS.
  - <intended-audience> é um valor permitido na reivindicação de público-alvo (aud) de um JWT para identificar o destinatário pretendido do token. Por exemplo, o público-alvo pode ser, mas não precisa ser, o nome do host do gateway de API. Você pode especificar um ou vários públicos-alvo (até cinco no máximo). Consulte Detalhes do Provedor de Identidades a Serem Usados para Reivindicações iss e aud e para o URI JWKS.
  - verifyClaims opcionalmente especifica nomes e valores de reivindicações adicionais para uma ou mais reivindicações extras a serem validadas em um JWT (até dez no máximo).
    - "key": "<claim-name>" é o nome de uma reivindicação que pode ou deve ser incluída em um JWT. O nome da reivindicação especificado pode ser um nome de reivindicação reservado, como a reivindicação de assunto (sub) ou um nome de reivindicação personalizado emitido por um provedor de identidades específico.
    - "values": ["<acceptable-value>", "<acceptable-value>"] (opcionalmente) indica um ou mais valores aceitáveis para a reivindicação.
    - "isRequired": <true|false> indica se a reivindicação deve ser incluída no JWT.
    Observe que todos os nomes e valores de chave informados são simplesmente tratados como strings e devem corresponder exatamente a nomes e valores no JWT. Correspondência de padrões e outros tipos de dados não são suportados
Por exemplo, a seguinte política authentication configura o gateway de API para validar o JWT no cabeçalho da solicitação de Autorização recuperando chaves de verificação públicas do provedor de identidades no runtime:
```
{
  "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"
      }
    }
  ]
}
```
Se você quiser que o gateway da API valide JWTs com chaves públicas de verificação já emitidas por um provedor (permitindo que o gateway da API verifique JWTs localmente sem precisar entrar em contato como provedor), adicione a seguinte política de validação à seção vazia validationPolicy:
```
      "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>
          }]
        }
      }
```
em que:
- "validationPolicy": {"type": "STATIC_KEYS"... especifica que você deseja configurar o gateway de API com até dez chaves públicas de verificação já emitidas por um provedor de identidades (permitindo que o gateway de API verifique os JWTs localmente sem precisar entrar em contato com o provedor de identidades).
- "keys": [{<key-config>}] especifica o identificador da chave estática usada para assinar o JWT. Os detalhes a serem fornecidos dependem do formato da chave já emitida pelo provedor de identidades (independentemente do formato, você pode especificar até dez chaves):
  - Se a chave estática for uma Chave Web JSON, especifique "format": "JSON_WEB_KEY", especifique o identificador da chave estática usada para assinar o JWT como o valor do parâmetro "kid" e forneça valores para outros parâmetros para verificar a assinatura do JWT.
    
    Por exemplo:
```
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ]
```
    Observe que determinados parâmetros devem estar presentes na chave estática para verificar a assinatura do JWT (consulte Parâmetros Chave Necessários para Verificar Assinaturas de JWT). Observe também que RSA é atualmente o único tipo de chave suportado (kty).
  - Se a chave estática for uma chave pública codificada por PEM, especifique "format": "PEM", especifique o identificador da chave estática usada para assinar o JWT como o valor de "kid" e forneça a chave como o valor de "key".
    
    Por exemplo:
```
        "keys": [
          {
            "format": "PEM",
            "kid": "master_key"
            "key": -----BEGIN PUBLIC KEY-----XsEiCeYgglwW/KAhSSNRVdD60QlXYMWHOhXzSFDZCLf1WXxKMZCiMvVrsBIzmFEXnFmcsO2mxwlL5/8qQudomoP+yycJ2gWPIgqsZcQRheJWxVC5ep0MeEHlvLnEvCi9utpAnjrsZCQ7plfZVPX7XORvezwqQhBfYzwA27M2FgOOs8DOIYfqQ1Ki3DMqEppFnjLcjgQtknbTlT7YgG6tzobwig8M2KIrPjJ0BmbJAFH-----END PUBLIC KEY-----
          }
        ]
```
    Observe que os marcadores -----BEGIN PUBLIC KEY----- e -----END PUBLIC KEY----- são obrigatórios.
- "isSslVerifyDisabled": <true|false> indica se a verificação SSL será desativada ao se comunicar com o provedor de identidades. A Oracle recomenda não definir essa opção para true porque ela pode equilibrar a validação de JWT. O API Gateway confia em certificados de várias Autoridades de Certificado emitidas para o OCI IAM com Domínios de Identidade, Oracle Identity Cloud Service (IDCS), Auth0 e Okta.
- "maxCacheDurationInHours": <cache-time> especifica o número de horas (entre 1 e 24) em que o gateway de API deve colocar em cache o JWKS após recuperá-lo.
- "additionalValidationPolicy": {"issuers": ...} especifica detalhes adicionais para validação de token:
  - <issuer-url> é o URL (ou uma sequência de caracteres de texto) de um provedor de identidades que é permitido na reivindicação do emissor (iss) de um JWT a ser usado para acessar a implantação da API. Por exemplo, para permitir que um JWT emitido pelo OCI IAM com Domínios de Identidade seja usado para acessar a implantação de API, informe https://identity.oraclecloud.com/ . Você pode especificar um ou vários provedores de identidade (até cinco no máximo). Consulte Detalhes do Provedor de Identidades a Serem Usados para Reivindicações iss e aud e para o URI JWKS.
  - <intended-audience> é um valor permitido na reivindicação de público-alvo (aud) de um JWT para identificar o destinatário pretendido do token. Por exemplo, o público-alvo pode ser, mas não precisa ser, o nome do host do gateway de API. Você pode especificar um ou vários públicos-alvo (até cinco no máximo). Consulte Detalhes do Provedor de Identidades a Serem Usados para Reivindicações iss e aud e para o URI JWKS.
  - verifyClaims opcionalmente especifica nomes e valores de reivindicações adicionais para uma ou mais reivindicações extras a serem validadas em um JWT (até dez no máximo).
    - "key": "<claim-name>" é o nome de uma reivindicação que pode ou deve ser incluída em um JWT. O nome da reivindicação especificado pode ser um nome de reivindicação reservado, como a reivindicação de assunto (sub) ou um nome de reivindicação personalizado emitido por um provedor de identidades específico.
    - "values": ["<acceptable-value>", "<acceptable-value>"] (opcionalmente) indica um ou mais valores aceitáveis para a reivindicação.
    - "isRequired": <true|false> indica se a reivindicação deve ser incluída no JWT.
    Observe que todos os nomes e valores de chave informados são simplesmente tratados como strings e devem corresponder exatamente a nomes e valores no JWT. Correspondência de padrões e outros tipos de dados não são suportados
Por exemplo, a seguinte política authentication configura o gateway de API com uma chave de verificação pública já emitida por um provedor de identidades para validar o JWT no cabeçalho da solicitação de Autorização:
```
{
  "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"
      }
    }
  ]
}
```
(Opcional) Você pode especificar como deseja que o gateway de API trate uma resposta de autenticação com falha (retornada após uma tentativa malsucedida de validar um token ausente ou inválido) configurando uma política de falha de validação:
1. Se você quiser que o gateway de API envie um código de status HTTP 401 e o cabeçalho WWW-Authenticate na resposta (a resposta padrão para um token ausente ou inválido), não defina uma política de falha de validação.
2. Se você quiser que o gateway de API use um fluxo de autorização do OpenID Connect para obter um novo token de acesso JWT, defina uma política de falha de validação do tipo OAUTH2. Observe que essa opção só estará disponível se você tiver especificado uma validationPolicy do tipo REMOTE_DISCOVERY anteriormente. Especifique:
```
{
  "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": [
    ...
  ]
}
```
  em que:
  - "scopes": ["<scope>", "<scope"] especifica um ou mais escopos de acesso a serem incluídos em uma reivindicação scope enviada ao servidor de autorização. Para usar o fluxo de autorização do OpenID Connect, inclua openid como um dos escopos. Por exemplo, "scopes": ["openid", "email:read", "profile"]
  - clientDetails": {...} especifica os detalhes do cliente a serem usados para obter um novo token de acesso JWT do servidor de autorização, da seguinte forma:
    - "type": "<VALIDATION_BLOCK|CUSTOM>" especifica se deve usar os mesmos detalhes do cliente ou detalhes diferentes daqueles especificados no validationPolicy anterior. Se você quiser usar os mesmos detalhes do cliente de antes (que geralmente é o caso), especifique "type": "VALIDATION_BLOCK" e não forneça detalhes adicionais. Se quiser usar detalhes de cliente diferentes, especifique "type": "CUSTOM" e defina valores para "clientId", "clientSecretId" e "clientSecretVersionNumber".
    - "clientId": "<client-id>" especifica o ID do cliente a ser enviado para o ponto final de introspecção. Usado somente se "type": "CUSTOM". Por exemplo, 5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1
    - "clientSecretId": "<secret-ocid>" especifica o OCID do segredo do vault que contém o segredo do cliente a ser enviado para o ponto final de introspecção. Usado somente se "type": "CUSTOM". Por exemplo, ocid1.vaultsecret.oc1.iad.amaaaaaa______cggit3q
    - "clientSecretVersionNumber": <secret-version-number> especifica a versão do segredo do vault que contém o segredo do cliente a ser enviado para o ponto final de introspecção. Usado somente se "type": "CUSTOM". Por exemplo, 1
  - "sourceUriDetails": {"type": "VALIDATION_BLOCK"} especifica que você deseja usar o mesmo URL especificado no validationPolicy anterior como o URL bem conhecido de um servidor de autorização do qual o gateway de API deve obter pontos finais de metadados de autorização.
  - "maxExpiryDurationInHours": <number-of-hours> especifica o período para armazenar em cache o token JWT gerado pelo fluxo de autorização. O padrão é 1.
  - "useCookiesForSession": <true|false> especifica como armazenar tokens JWT recém-gerados como strings não legíveis por humanos no final de um fluxo de autorização do OpenID Connect:
    - Defina essa opção como true se quiser armazenar o novo token JWT em um cookie de sessão. Para evitar possíveis ataques de CSRF, quando o gateway de API armazena o TOKEN em um cookie de sessão, ele também retorna um TOKEN CSRF em um cabeçalho de resposta X-CSRF-TOKEN. As solicitações subsequentes (além das solicitações GET) devem incluir o TOKEN CSRF em um cabeçalho de solicitação X-CSRF-TOKEN, além do TOKEN JWT no cookie de sessão que é incluído automaticamente.
    - Defina essa opção como false se não quiser armazenar o novo token JWT em um cookie de sessão. Em vez disso, o gateway de API retorna um TOKEN não legível por humanos em um cabeçalho de resposta X-APIGW-TOKEN. As solicitações subsequentes ao gateway de API devem incluir o mesmo TOKEN em um cabeçalho de solicitação X-APIGW-TOKEN.
    Consulte Observações sobre a Proteção contra CSRF (Cross-Site Request Forgery)
  - "useCookiesForIntermediateSteps": <true|false> especifica como armazenar valores de etapa intermediária do fluxo de autorização (por exemplo, parâmetros de solicitação). Defina esta opção como true para armazenar os valores nos cookies do navegador. Defina essa opção como false para armazenar os valores com o gateway de API.
  - "usePkce": <true|false> especifica se deve usar PKCE (Chave de Prova para Troca de Código) para segurança adicional. PKCE é uma extensão de segurança OAuth 2.0 para evitar CSRF (Cross-Site Request Forgery) e ataques de injeção de código de autorização. PKCE não substitui um segredo de cliente, e PKCE é recomendado mesmo se um segredo de cliente é usado. Para obter mais informações sobre PKCE, consulte a documentação do OAuth 2.0.
  - "responseType": "code" especifica o tipo de resposta necessária no fluxo de autorização. Especifique code como o tipo de resposta.
  - "fallbackRedirectPath": "/home" especifica opcionalmente um caminho relativo na implantação de API atual para a qual redirecionar clientes de API se a solicitação original fosse uma solicitação PUT ou POST. Por exemplo, /home.
    Se a solicitação original era uma solicitação GET, o processamento da solicitação é retomado com um novo token de acesso JWT, portanto, um caminho de fallback não é usado.
  - "logoutPath": "<revoke-path>"especifica opcionalmente um caminho relativo para um back-end de log-out na implantação de API atual. O caminho especificado deve corresponder ao caminho de rota definido para o back-end de log-out. Por exemplo, "logoutPath": "/revoke".
    Um cliente de API pode chamar o back-end de log-out para revogar tokens. Uma chamada para o back-end de log-out pode incluir um URL pós-log-out como um parâmetro de consulta chamado postLogoutUrl. Consulte Adicionando Log-out como um Back-End do API Gateway.
  Por exemplo:
```
{
  "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. Se você quiser personalizar a resposta para uma tentativa malsucedida de validar um token ausente ou inválido, defina uma política de falha de validação do tipo MODIFY_RESPONSE e especifique um código de status (e um corpo de mensagem opcional) para retornar ao cliente da API, da seguinte forma:
```
{
  "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": [
    ...
  ]
}
```
  em que:
  - responseCode: especifica um código de status HTTP alternativo. Por exemplo, 500.
  - responseMessage: (opcionalmente) especifica um corpo de mensagem. Por exemplo, Unfortunately, authentication failed. O corpo da mensagem pode incluir qualquer variável de contexto (exceto request.body).
  - responseTransformations: (opcionalmente) modifica os cabeçalhos da resposta que o gateway de API retorna ao cliente de API especificando uma política de resposta de transformação de cabeçalho. Para obter mais informações sobre políticas de transformação de cabeçalho, consulte Adicionando Políticas de Resposta de Transformação de Cabeçalho.
  Por exemplo:
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      ...
      "validationPolicy": {
        ...
      },
      "validationFailurePolicy": {
        "type": "MODIFY_RESPONSE",
        "responseCode": "500",
        "responseMessage": "Unfortunately, authentication failed.",
      }
    }
  },
  "routes": [
    ...
  ]
}
```

Adicione uma política de solicitação authorization para cada rota na especificação de implantação de API:

Insira uma seção requestPolicies após a primeira seção backend da rota, se ainda não existir. Por exemplo:

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

Adicione a seguinte política da authorization à nova seção da requestPolicies:
```
      "requestPolicies": {
        "authorization": {
          "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS">, 
          "allowedScope": [ "<scope>" ]
        }
      }
```
em que:
- "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS"> indica como conceder acesso à rota:
  - "AUTHENTICATION_ONLY": Só concede acesso a usuários finais que foram autenticados com sucesso. Nesse caso, a propriedade "isAnonymousAccessAllowed" na política authentication da especificação de implantação de API não tem efeito.
  - "ANY_OF": Só concede acesso a usuários finais autenticados com sucesso, desde que a reivindicação scope do JWT inclua um dos escopos de acesso especificados na propriedade allowedScope. Nesse caso, a propriedade "isAnonymousAccessAllowed" na política authentication da especificação de implantação de API não tem efeito.
  - "ANONYMOUS": Concede acesso a todos os usuários finais, mesmo que eles não tenham sido autenticados com sucesso. Nesse caso, você deve definir explicitamente a propriedade "isAnonymousAccessAllowed" como true na política authentication da especificação de implantação de API.
- "allowedScope": [ "<scope>" ] é uma lista delimitada por vírgulas de uma ou mais strings que correspondem aos escopos de acesso incluídos na reivindicação scope do JWT. Nesse caso, você deve definir a propriedade type como "ANY_OF" (a propriedade "allowedScope" será ignorada se a propriedade type estiver definida como "AUTHENTICATION_ONLY" ou "ANONYMOUS"). Observe também que, se você especificar mais de um escopo, o acesso à rota será concedido se algum dos escopos especificados estiver incluído na reivindicação scope do JWT.
Por exemplo, a política de solicitação a seguir define uma rota /hello que só permite que usuários finais autenticados com o escopo read:hello a acessem:
```
{
  "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" ]
        }
      }
    }
  ]
}
```
Adicione uma política de solicitação authorization para todas as rotas restantes na especificação de implantação de API.

Observação

Se você não incluir uma política authorization para uma rota específica, o acesso será concedido como se tal política não existisse e a propriedade type estivesse definida como "AUTHENTICATION_ONLY". Em outras palavras, independentemente da definição da propriedade isAnonymousAccessAllowed na política authentication da especificação de implantação de API:

somente usuários finais autenticados podem acessar a rota
todos os usuários autenticados podem acessar a rota, independentemente dos escopos de acesso na reivindicação scope do JWT
usuários finais anônimos não podem acessar a rota

Salve o arquivo JSON que contém a especificação de implantação de API.
Use a especificação de implantação de API ao criar ou atualizar uma implantação de API das seguintes formas:
- especificando o arquivo JSON na Console quando você seleciona a opção Fazer Upload de uma API de implantação existente
- especificando o arquivo JSON em uma solicitação à API REST do serviço API Gateway
Para obter mais informações, consulte Implantando uma API em um Gateway da API Criando uma Implantação de API e Updating an API Gateway.
(Opcional) Confirme se a API foi implantada com êxito, chamando-a (consulte Chamando uma API Implantada em um Gateway de API).

Documentação do Oracle Cloud Infrastructure

Editando um Arquivo JSON para Adicionar Políticas da Solicitação de Autenticação e Autorização de Token