Validando Tokens para Adicionar Autenticação e Autorização a Implantações de API

Você pode adicionar a funcionalidade de autenticação e autorização a um gateway de API fazendo com que o próprio gateway de API valide os tokens incluídos em uma solicitação (conforme descrito neste tópico). Como alternativa, você pode fazer com que o gateway de API passe um token de acesso de vários argumentos ou de um único argumento incluído em uma solicitação para uma função de autorizador implantada no OCI Functions para validação (conforme descrito em Passando Tokens para Funções de Autorizador para Adicionar Autenticação e Autorização a Implantações de API).

Para que o próprio gateway de API valide o token incluído em uma solicitação, crie uma política de solicitação de autenticação do tipo TOKEN_AUTHENTICATION. Os tokens que você usa para controlar o acesso a APIs geralmente são, mas nem sempre, JWTs (JSON Web Tokens).

Ao usar uma política TOKEN_AUTHENTICATION, você permite que uma implantação de API use tokens para autenticação e autorização incluindo dois tipos diferentes de política de solicitação na especificação de implantação de API:

Uma política de solicitação de autenticação para toda a implantação de API que especifica o uso de tokens, incluindo como validá-los e se os usuários finais não autenticados podem acessar rotas na implantação de API.
Uma política de solicitação de autorização para cada rota que especifica as operações que um usuário final tem permissão para executar, opcionalmente com base nos valores especificados para a reivindicação scope de um JWT.

Você pode adicionar políticas de solicitação de autenticação e autorização a uma especificação de implantação da API fazendo o seguinte:

Usando a Console.
Editando um arquivo JSON.

Observação

Em releases anteriores, você criou políticas de solicitação de autenticação do tipo JWT_AUTHENTICATION para usar JWTs para autenticação. Ainda há suporte para políticas de solicitação de autenticação JWT_AUTHENTICATION existentes (consulte Observações sobre o uso de políticas de solicitação JWT_AUTHENTICATION). No entanto, se você estiver criando novas políticas de solicitação de autenticação para autenticar JWTs, recomendamos que crie políticas de solicitação de autenticação como políticas TOKEN_AUTHENTICATION. O uso de políticas TOKEN_AUTHENTICATION permite:

Valide tokens JWT e tokens não JWT.
Valide tokens usando um provedor de identidades para obter um ponto final de introspecção.
Especifique políticas de falha de validação, incluindo a geração de um novo token JWT no caso de um token JWT inválido ou ausente na solicitação original.

O que acontece durante a autenticação de token?

Quando um gateway de API recebe uma solicitação de um cliente de API e você especificou uma política de autenticação de token, o gateway de API localiza um token (por exemplo, em um cabeçalho de token) e usa esse token.

Você especifica como o gateway de API valida o token obtido definindo a política de validação da política de autenticação de token como um dos seguintes tipos:

OAuth Ponto final de introspecção 2.0: Especifique esse tipo de política de validação se quiser que o gateway de API valide um token JWT ou não JWT com o ponto final de introspecção de um provedor de identidades. Você precisa especificar o URL de Descoberta do provedor de identidades do qual obter o ponto final de introspecção. Nesse caso, o gateway de API passa as credenciais do cliente (o id do cliente, juntamente com o segredo do cliente recuperado do serviço Vault) para o provedor de identidades para validar o token. O token é validado sem o uso de chaves públicas. Para tornar a validação futura mais rápida, você pode especificar que deseja que o gateway de API armazene em cache a resposta do ponto final de introspecção, por entre 1 hora (o padrão) e 24 horas. Se você estiver definindo a especificação de implantação de API em um arquivo JSON e quiser esse comportamento, inclua uma política de validação do tipo REMOTE_DISCOVERY.
JWKS Remoto: Especifique esse tipo de política de validação se quiser que o gateway de API use chaves de verificação públicas recuperadas de um provedor de identidades no runtime para verificar um JWT. Nesse caso, o gateway de API entra em contato com o provedor de identidades para verificar o JWT. O provedor de identidades atua como o servidor de autorização. Se você estiver definindo a especificação de implantação de API em um arquivo JSON e quiser esse comportamento, inclua uma política de validação do tipo REMOTE_JWKS.
Chaves estáticas: Especifique esse tipo de política de validação se quiser que o gateway de API use chaves de verificação públicas já emitidas por um provedor de identidades (conhecidas como 'chaves estáticas') para verificar um JWT. Nesse caso, o gateway de API pode verificar o JWT localmente no runtime sem precisar entrar em contato com o provedor de identidades. O resultado é uma validação de token mais rápida. Se você estiver definindo a especificação de implantação de API em um arquivo JSON e quiser esse comportamento, inclua uma política de validação do tipo STATIC_KEYS

Se a validação for bem-sucedida, o gateway de API roteará a solicitação para o ponto final de API apropriado.

Se a validação falhar devido a um token inválido ou ausente na solicitação original, você especificará o comportamento do gateway de API definindo a política de falha de validação da política de autenticação de token como um dos seguintes tipos:

Padrão (HTTP 401 Não Autorizado): Especifique esse tipo de política de falha de validação se quiser que o gateway de API retorne uma resposta HTTP-401 ao cliente de API. Esta é a resposta padrão. Se você estiver definindo a especificação de implantação de API em um arquivo JSON e quiser esse comportamento, simplesmente não inclua uma política de falha de validação.
Resposta personalizada: Especifique esse tipo de política de falha de validação se quiser que o gateway de API retorne uma resposta alternativa (uma resposta modificada) ao cliente de API, em vez de uma resposta HTTP-401. Se você estiver definindo a especificação de implantação de API em um arquivo JSON e quiser esse comportamento, inclua uma política de falha de validação do tipo MODIFY_RESPONSE.
OAuth 2.0: Especifique esse tipo de política de falha de validação se quiser que o gateway de API obtenha um token JWT novo e válido do provedor de identidades para solicitações GET (tendo primeiro armazenado com segurança os parâmetros de consulta de solicitação originais). Para solicitações PUT e POST, você pode especificar um caminho relativo na implantação de API atual para o qual redirecionar clientes de API. Usando esse tipo de política de falha de validação, você também pode definir um back-end de log-out para remover quaisquer cookies de sessão associados, revogar tokens chamando o ponto final da sessão final do provedor de identidades e redirecionar para um URL pós-log-out permitido. Se você estiver definindo a especificação de implantação de API em um arquivo JSON e quiser esse comportamento, inclua uma política de falha de validação do tipo OAUTH2.
Observe que as políticas de falha de validação do tipo OAuth 2.0 atualmente suportam apenas o fluxo de autorização do OpenID Connect e apenas a geração de token JWT (consulte Observações sobre OAuth 2.0 e OpenID Connect). No caso do fluxo de autorização do OpenID Connect, dois tokens chamados id_token (sempre codificados por JWT) e access_token (podem ser codificados por JWT) são retornados. O gateway de API salva os valores de token nas variáveis de contexto request.auth[id_token] e request.auth[access_token], juntamente com reivindicações personalizadas nas variáveis de contexto request.auth[id_token_claims][<claim-name>] e request.auth[access_token_claims][<claim-name>], respectivamente (consulte Adicionando Variáveis de Contexto a Políticas e Definições de Backend HTTP). Após o recebimento do novo token JWT id_token, o gateway de API recupera os detalhes da solicitação e retoma o processamento da solicitação usando o token.

O local do qual o gateway de API obtém um token depende do tipo de política de validação (uma das pontos finais de introspecção OAuth 2.0, JWKS Remoto ou Chaves estáticas) e do tipo de política de falha de validação (uma das opções Padrão (HTTP 401 Não Autorizado), Resposta personalizada ou OAuth 2.0), da seguinte forma:

Se você especificar uma política de validação do tipo OAuth 2.0 ponto final de introspecção e uma política de falha de validação do tipo OAuth 2.0, o gateway de API inicialmente tentará obter o token de um ou outro dos seguintes itens:
- Se você selecionou a opção Usar cookies para sessão na política de falha de validação, em um cookie de sessão.
- Caso contrário, a partir do cabeçalho X-APIGW-TOKEN na solicitação.
Se o gateway de API não puder obter um token do local inicial, o gateway de API obterá o token do cabeçalho de solicitação ou do parâmetro de consulta especificado na política de autenticação de token.
Se a validação do token for subsequentemente bem-sucedida e você tiver selecionado a opção Usar cookies para sessão, o gateway de API armazenará o token gerado como uma string não legível por humanos em um cookie de sessão. Se o cliente de API fizer uma solicitação subsequente, o token será obtido do cookie de sessão. Para evitar ataques de CSRF, quando o TOKEN gerado é armazenado em um cookie de sessão, o gateway de API também retorna um TOKEN CSRF em um cabeçalho de resposta X-CSRF-TOKEN (consulte Observações sobre a Proteção de falsificação de solicitação entre sites (CSRF)).
Se você não especificar uma política de validação do tipo OAuth 2.0 ponto final de introspecção e uma política de falha de validação do tipo OAuth 2.0, o gateway de API obterá o token do cabeçalho da solicitação ou do parâmetro de consulta especificado na política de autenticação de token.

Observações sobre JWTs (JSON Web Tokens)

Os tokens que você usa para controlar o acesso a APIs geralmente são JWTs (JSON Web Tokens). Um JWT é um token de acesso baseado em JSON enviado em uma solicitação HTTP de um cliente de API para um recurso. Os JWTs são emitidos por provedores de identidade. O Gateway de API suporta o uso de qualquer provedor de identidades compatível com OAuth2, como OCI IAM com Domínios de Identidade, Oracle Identity Cloud Service (IDCS), Auth0 e Okta. Se um JWT for necessário para acessar um recurso, o recurso validará o JWT com um servidor de autorização usando uma chave de verificação pública correspondente, chamando um ponto final de validação no servidor de autorização ou usando uma chave de verificação local fornecida pelo servidor de autorização.

Um JWT compreende:

Um cabeçalho, que identifica o tipo de token e o algoritmo criptográfico usado para gerar a assinatura.
Um payload, contendo reivindicações sobre a identidade do usuário final, e as propriedades do próprio JWT. Uma reivindicação é um par de chave-valor, em que a chave corresponde ao nome da reivindicação. Recomenda-se um payload (embora não seja necessário) para conter determinadas reivindicações reservadas com nomes específicos, como tempo de expiração (exp), público-alvo (aud), emissor (iss) e não antes (nbf). Um payload também pode conter reivindicações personalizadas com nomes definidos pelo usuário.
Uma assinatura, para validar a autenticidade do JWT (derivado pela codificação base64 do cabeçalho e do payload).

Ao usar JWTs para controlar o acesso a APIs, você pode especificar que as reivindicações reservadas no payload do JWT devem ter valores específicos para que o gateway de API considere o JWT válido. Por padrão, os gateways de API validam JWTs usando as reivindicações de expiração (exp), público-alvo (aud) e emissor (iss), juntamente com a reivindicação não antes (nbf), se presente. Também é possível especificar valores aceitáveis para reivindicações personalizadas. Consulte Detalhes do Provedor de Identidades a Serem Usados para Reivindicações iss e aud e para o URI JWKS.

Quando um JWT é validado, o gateway de API extrai reivindicações do payload do JWT como pares de chaves-valores e os salva como registros na tabela de contexto request.auth para uso pela implantação da API. Por exemplo, como variáveis de contexto para uso em uma definição de back-end de HTTP (consulte Adicionando Variáveis de Contexto a Políticas e Definições de Back-end de HTTP). Se o payload do JWT contiver a reivindicação scope, você poderá usar os valores da reivindicação nas políticas de solicitação de autorização para rotas individuais para especificar as operações que um usuário final tem permissão para executar.

Observações sobre o OAuth 2.0 e o OpenID Connect

O protocolo OAuth 2.0 permite a recuperação segura de recursos seguros, protegendo as credenciais do cliente. OAuth 2.0 é um protocolo flexível e seguro que conta com SSL (Secure Sockets Layer) para garantir que os dados entre servidores Web e navegadores permaneçam privados. Embora o OAuth 2.0 seja diferente do JWT e usado para diferentes fins, o OAuth 2.0 e o JWT são compatíveis. Como o protocolo OAuth2 não especifica o formato de tokens, os JWTs podem ser incorporados ao uso de OAuth2. Para obter mais informações sobre o OAuth 2.0, consulte a documentação OAuth 2.0.

O OpenID Connect é uma camada de identidade simples sobre o protocolo OAuth 2.0. O uso do OpenID Connect permite que gateways de API verifiquem a identidade de um cliente de API com base na autenticação executada por um servidor de autorização. O OpenID Connect também permite que gateways de API obtenham informações básicas de perfil sobre o cliente de API. Para obter mais informações sobre o OpenID Connect, consulte a documentação do OpenID Connect.

Notas sobre a proteção contra falsificação de solicitações entre locais (CSRF)

Um invasor pode montar um ataque CSRF explorando a existência de um cookie de navegador para fazer com que um usuário envie um comando não intencional para um aplicativo web, como um gateway de API. Se o aplicativo determinar que o usuário já foi autenticado com sucesso por causa da existência do cookie do navegador, o aplicativo executará o comando com consequências potencialmente prejudiciais.

Ao definir uma política de validação do tipo OAuth 2.0 ponto final de introspecção e uma política de falha de validação do tipo OAuth 2.0, você especifica como um gateway de API armazena um novo token JWT obtido usando o fluxo de autorização do OpenID Connect:

Selecione a opção Usar cookies para sessão 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. Solicitações de mutação subsequentes para o gateway de API (como solicitações POST, PUT e DELETE, mas não 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.
Observe que o gateway de API também armazena o token CSRF na variável de contexto request.auth[apigw_csrf_token]. Se o cliente da API não conseguir ler o cabeçalho de resposta inicial do X-CSRF-TOKEN por algum motivo, você poderá incluir a variável de contexto request.auth[apigw_csrf_token] em uma política de resposta de transformação de cabeçalho para adicionar um cabeçalho de resposta contendo o token CSRF a cada resposta retornada ao cliente da API. Essa abordagem garante que o cliente da API possa extrair com sucesso o token CSRF do cabeçalho de resposta para inclusão nos cabeçalhos de solicitação de mutação X-CSRF-TOKEN subsequentes que ele envia para o gateway de API. Veja um exemplo de política de resposta de transformação de cabeçalho adequada:
```
"responsePolicies": {
        "headerTransformations": {
          "setHeaders": {
            "items": [
              {
                "name": "MY-CSRF-TOKEN",
                "values": ["${request.auth[apigw_csrf_token]}"],
                "ifExists": "OVERWRITE"              }
            ]
          }
        }
      }
```
Para obter mais informações sobre políticas de resposta de transformação de cabeçalho, consulte Adicionando Políticas de Resposta de Transformação de Cabeçalho.
Não selecione a opção Usar cookies para sessão 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.

Para obter mais informações sobre CSRF, pesquise on-line.

Observações sobre o uso de políticas de solicitação JWT_AUTHENTICATION

Em releases anteriores, talvez você tenha criado políticas de solicitação de autenticação do tipo JWT_AUTHENTICATION para usar JWTs para autenticação.

Se você estiver criando novas políticas de solicitação de autenticação para usar JWTs, agora recomendamos que crie políticas de solicitação de autenticação do tipo TOKEN_AUTHENTICATION (consulte Usando a Console para Adicionar Políticas de Solicitação de Autorização e Autenticação de Token e Editando um Arquivo JSON para Adicionar Políticas de Solicitação de Autorização e Autenticação de Token). Também recomendamos que você migre políticas de solicitação JWT_AUTHENTICATION existentes para políticas TOKEN_AUTHENTICATION.

Observe que as políticas de solicitação JWT_AUTHENTICATION existentes ainda são suportadas no momento. Observe também que, embora você possa criar novas políticas de solicitação JWT_AUTHENTICATION (conforme descrito nas instruções originais na seção Usando uma Política de Solicitação de Autenticação JWT_AUTHENTICATION (não mais recomendada)), recomendamos que você crie políticas de solicitação de autenticação do tipo TOKEN_AUTHENTICATION.

Pré-requisitos para Autenticação de Token

Antes de ativar a autenticação e a autorização para implantações de API usando JWTs:

Um provedor de identidades compatível com OAuth2 (por exemplo, OCI IAM com Domínios de Identidade, Oracle Identity Cloud Service (IDCS), Auth0) já deverá ter sido configurado para emitir JWTs para usuários com permissão para acessar a implantação de API.
Se você quiser usar reivindicações personalizadas em políticas de autorização, o provedor de identidades deverá ser configurado para adicionar as reivindicações personalizadas aos JWTs emitidos por ele.

Consulte a documentação do provedor de identidades para obter mais informações (por exemplo, a documentação do OCI IAM com Domínios de Identidades, a documentação do Oracle Identity Cloud Service (IDCS), a documentação Auth0).

Para validar um JWT usando uma chave de verificação pública correspondente fornecida pelo provedor de identidades emissor:

o algoritmo de assinatura usado para gerar a assinatura do JWT deve ser um dos seguintes: RS256, RS384 ou RS512
a chave de verificação pública deve ter um tamanho mínimo de 2048 bits e não deve exceder 4096 bits

Para validar tokens usando o ponto final de introspecção de um servidor de autorização:

Você já deve ter criado e registrado um aplicativo cliente no servidor de autorização para obter credenciais do cliente (um ID de cliente e um segredo de cliente). Consulte a documentação do servidor de autorização para obter mais informações (por exemplo, a documentação do OCI IAM com Domínios de Identidade, a documentação do Oracle Identity Cloud Service (IDCS), a documentação Auth0).
Você já deve ter armazenado o segredo do cliente obtido do servidor de autorização como segredo em um vault no serviço Vault (consulte Criando um Segredo em um Vault) e deve saber o OCID e o número da versão do segredo.
Você já deve ter configurado uma política para conceder aos gateways de API em um grupo dinâmico permissão para acessar o segredo do vault que contém o segredo do cliente (consulte Criar uma Política para Conceder aos Gateways de API Acesso às Credenciais Armazenadas como Segredos no Serviço Vault).

usando a console para adicionar políticas de solicitação de autenticação e autorização de token

Para adicionar políticas de solicitação de autenticação e autorização a uma especificação de implantação de API usando a Console:

Crie ou atualize uma implantação de API usando a Console. Selecione a opção Totalmente Nova e insira os detalhes na página Informações Básicas.

Para obter mais informações, consulte Implantando uma API em um Gateway de API por meio da Criação de uma Implantação de API e Atualizando um Gateway de API.
Selecione Próximo para exibir a página Autenticação.
Selecione Autenticação Única para especificar que você deseja usar um único servidor de autenticação para todas as solicitações.

Estas instruções pressupõem que você deseja usar um único servidor de autenticação. Como alternativa, se você quiser usar vários servidores de autenticação, selecione Multiautenticação e siga as instruções em Usando a Console para Adicionar Vários Servidores de Autenticação à mesma Implantação de API.
Marque ou desmarque a caixa de seleção Ativar Acesso Anônimo: para especificar se os usuários finais não autenticados (ou seja, anônimos) podem acessar rotas na implantação de API.

Por padrão, essa opção não está selecionada. Se você nunca quiser que usuários anônimos possam acessar rotas, não selecione essa opção. Observe que, se você selecionar essa opção, também precisará especificar explicitamente cada rota para a qual o acesso anônimo é permitido, selecionando Anônimo como o Tipo de Autorização em cada política de autorização da rota.
Selecione OAuth 2.0 / OpenID Connect na lista de opções Tipo de autenticação e especifique:
- Local do token: Se os tokens estão contidos em um cabeçalho de solicitação ou em um parâmetro de consulta.
- Detalhes do token de autenticação: Dependendo de os tokens estarem contidos em um cabeçalho de solicitação ou em um parâmetro de consulta, especifique:
  - Nome do cabeçalho do token: e Esquema de autenticação: Se os tokens estiverem contidos em um cabeçalho de solicitação, digite o nome do cabeçalho (Authorization, por exemplo) e o esquema de autenticação HTTP (somente Bearer é suportado no momento).
  - Nome do parâmetro de token: Se os tokens estiverem contidos em um parâmetro de consulta, informe o nome do parâmetro de consulta.
Especifique como você deseja que o gateway de API valide tokens:
1. 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 OAuth 2.0 usando credenciais do cliente (incluindo um segredo do cliente recuperado de um vault no serviço Vault), selecione OAuth 2.0 ponto final de introspecção na lista Tipo e especifique:
  - ID do Cliente: O ID do cliente a ser enviado ao ponto final de introspecção. Você obtém um ID de cliente criando e registrando um aplicativo cliente no servidor de autorização. Por exemplo, 5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1 . Consulte Pré-requisitos para Autenticação de Token.
  - Vault em <compartment-name>: O nome de um vault no serviço Vault que contém o segredo do cliente a ser enviado ao ponto final de introspecção. Você obtém um segredo do cliente criando e registrando um aplicativo cliente no servidor de autorização. Consulte Pré-requisitos para Autenticação de Token.
  - Segredo do vault em <nome do compartimento>: O nome de um segredo do vault que contém o segredo do cliente a ser enviado ao ponto final de introspecção.
  - Número da versão do segredo do vault: A versão do segredo do vault que contém o segredo do cliente a ser enviado ao ponto final de introspecção.
  - URL de Descoberta: O URL bem conhecido do 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 que contém o gateway de API no qual a API está implantada.
  - Duração máxima do cache em horas: O número de horas (entre 1 e 24) que o gateway de API deve armazenar em cache a resposta do ponto final de introspecção.
  - Distribuição máxima do relógio em segundos: (Opcional) A diferença de tempo máxima entre os relógios do sistema do servidor de autorização que emitiu um token e o gateway de API. O valor informado aqui é levado em conta quando o gateway de API valida um 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.
  - Desativar verificação de SSL: Se a verificação de SSL deve ser desativada ao se comunicar com o servidor de autorização. Por padrão, essa opção não está selecionada. A Oracle recomenda não selecionar esta opção porque ela pode comprometer a validação do token. O Gateway de API confia em certificados de várias Autoridades de Certificação emitidos para o OCI IAM com Domínios de Identidades, Oracle Identity Cloud Service (IDCS), Auth0 e Okta.
2. Se você quiser que o gateway de API valide JWTs recuperando chaves de verificação públicas do provedor de identidades no runtime, selecione JWKS Remoto na lista Tipo e especifique:
  - URI JWKS: O URI do qual será recuperado o conjunto de chaves Web JSON (JWKS) a ser usado para verificar a assinatura em JWTs. Por exemplo, https://www.somejwksprovider.com/oauth2/v3/certs. 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.
  - Duração máxima do cache em horas: O número de horas (entre 1 e 24) que o gateway de API deve armazenar em cache o JWKS após recuperá-lo.
  - Ativar verificação de SSL: Se a verificação de SSL deve ser desativada ao se comunicar com o provedor de identidades. Por padrão, essa opção não está selecionada. A Oracle recomenda não selecionar esta opção porque ela pode comprometer a validação do JWT. O Gateway de API confia em certificados de várias Autoridades de Certificação emitidos para o OCI IAM com Domínios de Identidades, Oracle Identity Cloud Service (IDCS), Auth0 e Okta.
3. Se você quiser que o gateway de API valide JWTs com chaves de verificação públicas já emitidas por um provedor de identidades (permitindo que o gateway de API verifique JWTs localmente sem precisar entrar em contato com o provedor de identidades), selecione Chave estáticas na lista Tipo e especifique até dez chaves estáticas:
  - ID da Chave: O identificador da chave estática usado para assinar o JWT. O valor deve corresponder à reivindicação kid no cabeçalho do JWT. Por exemplo, master_key.
  - Formato de chave: O formato da chave estática, como uma Chave Web JSON ou uma Chave Pública codificada por PEM.
    - Chave da Web JSON: Se a chave estática for uma Chave da Web JSON, cole a chave neste campo.
      
      Por exemplo:
```
{
  "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).
    - Chave pública codificada por PEM: Se a chave estática for uma chave pública codificada por PEM, cole a chave neste campo. Por exemplo:
```
-----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.
  - Outra chave: Selecione para adicionar mais chaves (até dez no máximo).
(Opcional) Especifique detalhes adicionais para validação de token JWT:
1. Na seção Emissores, especifique valores permitidos na reivindicação (iss) do emissor de um JWT que está sendo usado para acessar a implantação de API:
  - Emissores Permitidos: Especifique o URL (ou uma string de texto) para um provedor de identidades permitido na reivindicação do emissor (iss) de um JWT a ser usado para acessar a implantação de 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/. Consulte Detalhes do Provedor de Identidades a Serem Usados para Reivindicações iss e aud e para o URI JWKS.
  - Outro Emissor: Selecione para adicionar mais provedores de identidades (até cinco no máximo).
2. Na seção Públicos-alvo, especifique valores permitidos na reivindicação de público (aud) de um JWT que está sendo usado para acessar a implantação de API:
  - Públicos-alvo Permitidos: especifique 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. Consulte Detalhes do Provedor de Identidades a Serem Usados para Reivindicações iss e aud e para o URI JWKS.
  - Another Audience: Selecione para adicionar mais públicos-alvo (até cinco no máximo).
3. Validação de reivindicações: (Opcional) Além dos valores das reivindicações de público-alvo aud e do emissor iss já especificados, é possível especificar nomes e valores para uma ou mais reivindicações adicionais a serem validadas em um 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.
  - A reivindicação é obrigatória: Especifique se a reivindicação no campo Chave da reivindicação deve ser incluída no JWT.
  - Chave da reivindicação: (Opcional) Especifique o nome de uma reivindicação que pode ou deve ser incluída em um JWT. Se a reivindicação precisar ser incluída no JWT, selecione Obrigatório. 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.
  - Valores da reivindicação: (Opcional) Especifique um valor aceitável para a reivindicação no campo Chave da reivindicação. Selecione o sinal de adição (+) para informar outro valor aceitável. Se você especificar um ou mais valores aceitáveis para a reivindicação, o gateway de API validará se a reivindicação tem um dos valores especificados.
  Observe que você pode especificar uma reivindicação em um JWT sem especificar um valor para ela. Para fazer isso, informe o nome da reivindicação no campo Chave da reivindicação, deixe o campo Valores da reivindicação em branco e defina A reivindicação é obrigatória conforme apropriado.
Especifique como você 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), selecione Padrão (HTTP 401 Não Autorizado).
2. Se quiser que o gateway de API use um fluxo de autorização do OpenID Connect para obter um novo token de acesso JWT, selecione OAuth 2.0. Observe que essa opção só estará disponível se você tiver selecionado OAuth 2.0 ponto final de introspecção na lista Tipo de Validação anteriormente. Especifique:
  - Escopos: 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, openid, email:read, profile.
  - Tipo de resposta: O tipo de resposta necessário do fluxo de autorização. Informe code como o tipo de resposta.
  - Caminho de redirecionamento de fallback: (opcional) Um caminho relativo na implantação de API atual para o qual redirecionar clientes de API se a solicitação original for uma solicitação PUT ou POST. Por exemplo, /home
    Se a solicitação original for uma solicitação GET, o processamento da solicitação será retomado com um novo token de acesso JWT, portanto, um caminho de fallback não será usado.
  - Caminho de log-out: (opcional) 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, /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 de pós-log-out como um parâmetro de consulta chamado postLogoutUrl. Consulte Adicionando Log-out como Back-end do Serviço API Gateway.
  - Expiração da resposta em horas: (opcional) O período de tempo para armazenar em cache o token JWT gerado pelo fluxo de autorização. O default é 1 hora.
  - Usar credenciais do cliente do ponto final de introspecção OAuth2: Especifique se deseja usar os mesmos detalhes do cliente especificados anteriormente para o ponto final de introspecção OAuth 2.0 para obter um novo token de acesso JWT (que geralmente é o caso). Se você não quiser usar os detalhes especificados anteriormente, informe outros detalhes do cliente a serem usados para obter um novo token de acesso JWT do servidor de autorização, da seguinte forma:
    - ID do Cliente: O ID do cliente a ser enviado ao ponto final de introspecção. Por exemplo, 5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1
    - Vault em <compartment-name>: O nome de um vault no serviço Vault que contém o segredo do cliente a ser enviado ao ponto final de introspecção.
    - Segredo do vault em <nome do compartimento>: O nome do segredo do vault que contém o segredo do cliente a ser enviado ao ponto final de introspecção.
    - Número da versão do segredo do vault: A versão do segredo do vault que contém o segredo do cliente a ser enviado ao ponto final de introspecção.
  Opcionalmente, você pode optar por armazenar nos cookies os tokens e valores obtidos durante os fluxos de autorização OpenID, selecionando Mostrar opções avançadas e selecionando:
  - Usar cookies para sessão: (opcional) Especifique 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:
    - Selecione esta opção se quiser armazenar o novo token JWT em um cookie de sessão. Para evitar possíveis ataques 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 ao gateway de API (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.
    - Não selecione esta opção 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 Proteção contra Falsificação de Solicitação entre Locais (CSRF)
  - Usar cookies para etapas intermediárias: (opcional) Especifique como armazenar valores de etapas intermediárias do fluxo de autorização (por exemplo, parâmetros de solicitação). Selecione esta opção para armazenar os valores nos cookies do navegador. Desmarque essa opção para armazenar os valores com o gateway de API.
  - Usar PKCE: (opcional) Especifique 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 ataques de injeção de código de autorização e CSRF (Cross-Site Request Forgery). PKCE não substitui um segredo de cliente, e PKCE é recomendado mesmo que um segredo de cliente seja usado. Para obter mais informações sobre PKCE, consulte a documentação OAuth 2.0.
3. Se você quiser personalizar a resposta para uma tentativa malsucedida de validar um token ausente ou inválido, selecione Resposta personalizada e especifique um código de status (e um corpo de mensagem opcional) para retornar ao cliente de API:
  - Código de status HTTP: Informe um código de status HTTP alternativo. Por exemplo, 500.
  - Corpo da mensagem: Informe um corpo da mensagem. Por exemplo, Unfortunately, authentication failed.O corpo da mensagem pode incluir qualquer variável de contexto (exceto request.body).
  - Opcionalmente, modifique 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.
Selecione Próximo para informar detalhes de rotas individuais na implantação de API na página Rotas.
Na seção Rota 1, especifique a primeira rota na implantação de API que mapeia um caminho e um ou mais métodos para um serviço de back-end:
- Caminho: Um caminho para chamadas de API usando os métodos listados para o serviço de back-end. Observe que o caminho da rota que você especificar:
  - é relativo ao prefixo do caminho de implantação
  - deve ser precedido por uma barra ( / ) e pode ser apenas uma barra
  - pode conter várias barras (desde que elas não sejam adjacentes) e pode terminar com uma barra
  - pode incluir caracteres alfanuméricos maiúsculos e minúsculos
  - pode incluir os caracteres especiais $ - _ . + ! * ' ( ) , % ; : @ & =
  - pode incluir parâmetros e curingas (consulte Adicionando Parâmetros de Caminho e Curingas a Caminhos de Rota)
- Métodos: Um ou mais métodos aceitos pelo serviço de back-end, separados por vírgulas. Por exemplo, GET, PUT.
- Adicionar um único backend ou Adicionar vários backends: Se todas as solicitações devem ser roteadas para o mesmo back-end ou para rotear solicitações para diferentes back-ends de acordo com a variável de contexto e as regras informadas.
  
  Essas instruções pressupõem que você deseja usar um único back-end; portanto, selecione Adicionar um único backend. Como alternativa, se você quiser usar back-ends diferentes, selecione Adicionar vários back-ends e siga as instruções em Usando a Console para Adicionar Seleção de Back-End Dinâmico a uma Especificação de Implantação de API.
- Tipo de backend: O tipo do serviço de backend, como:
  - HTTP: Para um back-end de HTTP, você também precisa especificar um URL, detalhes de timeout e se deve desativar a verificação SSL (consulte Adicionando um URL HTTP ou HTTPS como um Back-End do Serviço API Gateway).
  - Oracle Functions: Para um back-end do OCI Functions, você também precisa especificar o aplicativo e a função (consulte Adicionando uma Função no OCI Functions como um Back-End do Serviço API Gateway).
  - Resposta Padrão: Para um back-end de resposta padrão, você também precisa especificar o código de status HTTP, o conteúdo no corpo da resposta e um ou mais campos de cabeçalho HTTP (consulte Adicionando Respostas Padrão como um Back-End do Serviço API Gateway).
  - Log-out: Para um back-end de log-out, você também precisa especificar uma lista de URLs permitidos para os quais uma solicitação pode ser redirecionada para revogar tokens e, opcionalmente, dados a serem passados para o URL de log-out (consulte Adicionando Log-out como um Back-End do Serviço API Gateway).
Para especificar uma política de autorização que se aplique a uma rota individual, selecione Mostrar Políticas de Solicitação de Rota, selecione o botão Adicionar ao lado de autorização e especifique:
- Tipo de Autorização: Como conceder acesso à rota. Especifique:
  - Qualquer um: Só concede acesso a usuários finais que foram autenticados com sucesso, desde que o JWT tenha uma reivindicação scope que inclua pelo menos um dos escopos de acesso especificados no campo Escopo Permitido. Nesse caso, a opção Ativar Acesso Anônimo da política de autenticação não tem efeito.
  - Anônimo: Concede acesso a todos os usuários finais, mesmo que eles não tenham sido autenticados com sucesso usando o JWT. Nesse caso, você deve ter selecionado a opção Ativar Acesso Anônimo da política de autenticação.
  - Somente autenticação: Só concede acesso a usuários finais que foram autenticados com sucesso usando o JWT. Nesse caso, a opção Ativar Acesso Anônimo da política de autenticação não tem efeito.
- Escopo Permitido: Se você tiver selecionado Qualquer um como o Tipo de Autorização, informe uma lista delimitada por vírgulas de uma ou mais strings que correspondem aos escopos de acesso no JWT. O acesso só será concedido a usuários finais autenticados com sucesso se o JWT tiver uma reivindicação scope que inclua um dos escopos de acesso especificados. Por exemplo, read:hello
Observação

Se você não incluir uma política de autorização para uma rota específica, o acesso será concedido como se tal política existisse e o Tipo de Autorização estivesse definido como Somente autenticação. Em outras palavras, independentemente da definição da opção Ativar Acesso Anônimo da política de autenticação:
- 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
Selecione Aplicar Alterações e, em seguida, selecione Próximo para revisar os detalhes informados para a implantação de API.
Selecione Criar ou Salvar Alterações para criar ou atualizar a implantação de API.
(Opcional) Confirme se a API foi implantada com êxito, chamando-a (consulte Chamando uma API Implantada em um Gateway de API).

Editar arquivo JSON para adicionar políticas de solicitação de autenticação e autorização de token

Para adicionar políticas de solicitação de autenticação e autorização a uma especificação de implantação de 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, um URL ou o OCID de uma função no OCI Functions.
Por exemplo, a seguinte especificação básica de implantação de API define uma função simples sem servidor Hello World no OCI Functions como um único back-end:
```
{
  "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 existir 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, se for o caso, o nome do cabeçalho) ou um parâmetro de consulta que contém o token (e, se for o caso, o nome do parâmetro de 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 de autenticação a 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 especificado é levado em consideração quando o gateway de 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 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 o ponto final de introspecção do servidor de autorização OAuth 2.0 usando credenciais do cliente (incluindo um segredo do cliente recuperado de um vault no serviço Vault).
- clientDetails": {"type": "CUSTOM"...} especifica 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 ao ponto final de introspecção. Você obtém um ID de cliente criando e registrando um aplicativo cliente no 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 ao 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 ao 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 que contém o gateway de API no qual a API está implantada.
- "isSslVerifyDisabled": <true|false> indica se a verificação SSL será desativada ao se comunicar com o servidor de autorização. A Oracle recomenda não definir esta opção como true porque ela pode comprometer a validação do JWT. O Gateway de API confia em certificados de várias Autoridades de Certificação emitidos para o OCI IAM com Domínios de Identidades, 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 armazenar em cache a resposta do ponto final de introspecção.
- "additionalValidationPolicy": {"issuers": ...} especifica detalhes adicionais para validação de token:
  - <issuer-url> é o URL (ou uma string de texto) de um servidor de autorização que é permitido na reivindicação de emissor (iss) de um JWT a ser usado para acessar a implantação de 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": {...} opcionalmente especifica nomes e valores de reivindicações adicionais para uma ou mais reivindicações adicionais a serem validadas em um JWT (até 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 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 servidor de autorização 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 política authentication a seguir 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 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 esta opção como true porque ela pode comprometer a validação do JWT. O Gateway de API confia em certificados de várias Autoridades de Certificação emitidos para o OCI IAM com Domínios de Identidades, 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 armazenar em cache no JWKS após recuperá-lo.
- "additionalValidationPolicy": {"issuers": ...} especifica detalhes adicionais para validação de token:
  - <issuer-url> é o URL (ou uma string de texto) de um provedor de identidades que é permitido na reivindicação de emissor (iss) de um JWT a ser usado para acessar a implantação de 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 de API valide JWTs com chaves de verificação públicas já emitidas por um provedor de identidades (permitindo que o gateway de API verifique JWTs localmente sem precisar entrar em contato com o provedor de identidades), adicione a seguinte política de validação à seção validationPolicy vazia:
```
      "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 de verificação públicas já emitidas por um provedor de identidades (permitindo que o gateway de API verifique JWTs localmente sem precisar entrar em contato com o provedor de identidades).
- "keys": [{<key-config>}] especifique o identificador da chave estática usado 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 esta opção como true porque ela pode comprometer a validação do JWT. O Gateway de API confia em certificados de várias Autoridades de Certificação emitidos para o OCI IAM com Domínios de Identidades, 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 armazenar em cache no JWKS após recuperá-lo.
- "additionalValidationPolicy": {"issuers": ...} especifica detalhes adicionais para validação de token:
  - <issuer-url> é o URL (ou uma string de texto) de um provedor de identidades que é permitido na reivindicação de emissor (iss) de um JWT a ser usado para acessar a implantação de 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 a 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 um 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 os detalhes do cliente devem ser usados iguais ou diferentes dos especificados no validationPolicy anterior. Se você quiser usar os mesmos detalhes do cliente anteriores (que geralmente é o caso), especifique "type": "VALIDATION_BLOCK" e não forneça detalhes adicionais. Se quiser usar diferentes detalhes do cliente, especifique "type": "CUSTOM" e defina valores para "clientId", "clientSecretId" e "clientSecretVersionNumber".
    - "clientId": "<client-id>" especifica o ID do cliente a ser enviado ao 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 ao 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 ao 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 tempo 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 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 Proteção contra Falsificação de Solicitação entre Locais (CSRF)
  - "useCookiesForIntermediateSteps": <true|false> especifica como armazenar valores de etapa intermediária do fluxo de autorização (por exemplo, parâmetros de solicitação). Defina essa opção como true para armazenar os valores nos cookies do browser. 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 ataques de injeção de código de autorização e CSRF (Cross-Site Request Forgery). PKCE não substitui um segredo de cliente, e PKCE é recomendado mesmo que um segredo de cliente seja usado. Para obter mais informações sobre PKCE, consulte a documentação OAuth 2.0.
  - "responseType": "code" especifica o tipo de resposta necessário do 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 o qual redirecionar clientes de API se a solicitação original fosse uma solicitação PUT ou uma solicitação POST. Por exemplo, /home.
    Se a solicitação original for uma solicitação GET, o processamento da solicitação será retomado com um novo token de acesso JWT, portanto, um caminho de fallback não será 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 de pós-log-out como um parâmetro de consulta chamado postLogoutUrl. Consulte Adicionando Log-out como Back-end do Serviço 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 a 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 de 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 authorization à nova seção 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ê selecionar a opção Carregar uma API 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 de API por meio da Criação de uma Implantação de API e Atualizando um Gateway de API.
(Opcional) Confirme se a API foi implantada com êxito, chamando-a (consulte Chamando uma API Implantada em um Gateway de API).

Detalhes do Provedor de Identidades a Serem Usados para Reivindicações iss e aud e para o URI JWKS

O provedor de identidades que emitiu o JWT determina os valores permitidos que você precisa especificar para as reivindicações de emissor (iss) e de público-alvo (aud) no JWT. O provedor de identidades que emitiu o JWT também determina o URI do qual será recuperado o JWKS (JSON Web Key Set) para verificar a assinatura no JWT.

Observe que, independentemente do provedor de identidades, um JWKS pode conter no máximo dez chaves.

Use a tabela a seguir para descobrir o que especificar para JWTs emitidos pelos provedores de identidades do OCI IAM com Domínios de Identidades, Oracle Identity Cloud Service (IDCS), Okta e Auth0.


Provedor de identidades	Reivindicação de emissor (`iss`)	Reivindicação de público-alvo (`aud`)	Formato do URI do qual o JWKS será recuperado
OCI IAM com Domínios de Identidade	https://identity.oraclecloud.com	Específico do cliente. Consulte Gerenciando Aplicativos na documentação do OCI IAM com Domínios de Identidades.	https://<tenant-base-url>/admin/v1/SigningCert/jwk
IDCS	https://identity.oraclecloud.com/	Específico do cliente. Consulte Validando Tokens de Acesso na documentação do Oracle Identity Cloud Service.	https://<tenant-base-url>/admin/v1/SigningCert/jwk Para obter o JWKS sem fazer log-in no Oracle Identity Cloud Service, consulte Alterar Definições Padrão na documentação do Oracle Identity Cloud Service.
Okta	https://<your-okta-tenant-name>.com	Específico do cliente. O público-alvo configurado para o Servidor de Autorização na Console do Desenvolvedor do Okta. Consulte Additional validation for access tokens na documentação do Okta.	https://<your-okta-tenant-name>.com/oauth2/<auth-server-id> /v1/keys Consulte a documentação do Okta.
Auth0	https://<your-account-name>.auth0.com/	Específico do cliente. Consulte Audience na documentação do Auth0.	https://<your-account-name>.auth0.com/.well-known/jwks.json

Parâmetros de Chave Necessários para Verificar Assinaturas de JWT

Para verificar a assinatura em um JWT, os gateways de API exigem que os seguintes parâmetros de chave estejam presentes no JWKS retornado de um URI ou na Chave Web JSON estática especificada.


Parâmetro de chave	Observações
`kid`	O identificador da chave usada para assinar o JWT. O valor deve corresponder à reivindicação `kid` no cabeçalho do JWT. Por exemplo, `master_key`.
`kty`	O tipo da chave usada para assinar o JWT. Observe que o RSA é atualmente o único tipo de chave suportado.
`use` ou `key_ops`	Se o parâmetro `use` estiver presente, ele deverá ser definido como `sig`. Se o parâmetro `key-ops` estiver presente, `verify` deverá ser um dos valores válidos.
`n`	O módulo de chave pública.
`e`	O expoente de chave pública.
`alg`	O algoritmo de assinatura (se presente) deve ser definido como um dos seguintes: RS256, RS384 ou RS512.

Usando uma Política de Solicitação de Autenticação JWT_AUTHENTICATION (não mais recomendada)

Observação

Em releases anteriores, talvez você tenha criado políticas de solicitação de autenticação do tipo JWT_AUTHENTICATION para usar JWTs para autenticação.

Observe que as políticas de solicitação JWT_AUTHENTICATION existentes ainda são suportadas no momento. Observe também que, embora você possa criar novas políticas de solicitação JWT_AUTHENTICATION definindo a especificação de implantação de API em um arquivo JSON (conforme descrito nas instruções originais nesta seção), recomendamos que você crie políticas de solicitação de autenticação do tipo TOKEN_AUTHENTICATION.

Ao usar uma política de solicitação de autenticação do tipo JWT_AUTHENTICATION, para que um usuário final possa acessar uma implantação de API que use JWTs para autenticação e autorização, ele deverá obter um JWT de um provedor de identidades.

Ao chamar uma API implantada em um gateway de API, o cliente de API fornece o JWT como um parâmetro de consulta ou no cabeçalho da solicitação. O gateway de API valida o JWT usando uma chave de verificação pública correspondente fornecida pelo provedor de identidades emissor. Usando a política de solicitação de autenticação JWT_AUTHENTICATION da implantação de API, você pode configurar como o gateway de API valida JWTs:

Você pode configurar o gateway de API para recuperar chaves de verificação públicas do provedor de identidades no runtime. Nesse caso, o provedor de identidades atua como o servidor de autorização.
Você pode configurar o gateway API com antecedência com chaves de verificação públicas já emitidas por um provedor de identidades (conhecido como "chaves estáticas"), permitindo que o gateway de API verifique JWTs localmente no runtime sem precisar entrar em contato com o provedor de identidades. O resultado é uma validação de token mais rápida.

Para adicionar uma nova política de solicitação de autenticação e autorização JWT_AUTHENTICATION a uma especificação de implantação de API em um arquivo JSON:

Adicione uma política de solicitação authentication que se aplique a todas as rotas na especificação de implantação de API:
1. Insira uma seção requestPolicies antes da seção routes, se ainda não existir uma. Por exemplo:
```
{
  "requestPolicies": {},
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
         "type": "ORACLE_FUNCTIONS_BACKEND",
         "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
2. Adicione a seguinte política authentication à nova seção 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"
      }
    }
  ]
}
```
  em que:
  - "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.
  - <issuer-url> é o URL (ou uma string de texto) de um provedor de identidades que é permitido na reivindicação de emissor (iss) de um JWT a ser usado para acessar a implantação de 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.
  - <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>"> indica se é um cabeçalho de solicitação que contém o JWT (e, se for o caso, o nome do cabeçalho) ou um parâmetro de consulta que contém o JWT (e, se for o caso, o nome do parâmetro de consulta). Observe que você pode especificar "tokenHeader": "<token-header-name>" ou "tokenQueryParam": "<token-query-param-name>">, mas não ambos.
  - <tokenAuthScheme> é o nome do esquema de autenticação a ser usado se o JWT estiver contido em um cabeçalho de solicitação. Por exemplo, "Bearer".
  - <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.
  - "type": <"REMOTE_JWKS"|"STATIC_KEYS"> indica como você deseja que o gateway de API valide JWTs usando chaves de verificação públicas. Especifique REMOTE_JWKS para configurar o gateway de API para recuperar até dez chaves de verificação públicas do provedor de identidades no runtime. Especifique STATIC_KEYS para configurar o gateway de API com até dez chaves de verificação públicas já emitidas por um provedor de identidades (permitindo que o gateway de API verifique JWTs localmente sem precisar entrar em contato com o provedor de identidades).
  - <public-key-config> fornece os detalhes da validação de JWT, de acordo com se você especificou "REMOTE_JWKS" ou "STATIC_KEYS" como o valor de "type": da seguinte forma:
    - Se você especificou "type": "REMOTE_JWKS" para configurar o gateway de API para validar JWTs recuperando chaves de verificação públicas do provedor de identidades no runtime, forneça detalhes da seguinte forma:
      "publicKeys": { "type": "REMOTE_JWKS", "uri": "<uri-for-jwks>", "maxCacheDurationInHours": <cache-time>, "isSslVerifyDisabled": <true|false> }
      em que:
      - "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.
      - "maxCacheDurationInHours": <cache-time> especifica o número de horas (entre 1 e 24 que o gateway de API deve armazenar em cache no JWKS após recuperá-lo.
      - "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 esta opção como trueporque ela pode comprometer a validação do JWT. O Gateway de API confia em certificados de várias Autoridades de Certificação emitidos para o OCI IAM com Domínios de Identidades, Oracle Identity Cloud Service (IDCS), Auth0 e Okta.
      Por exemplo:
      "publicKeys": { "type": "REMOTE_JWKS", "uri": "https://www.somejwksprovider.com/oauth2/v3/certs", "maxCacheDurationInHours": 3, "isSslVerifyDisabled": false }
    - Se você especificou "type": "STATIC_KEYS", os detalhes a serem fornecidos dependerão 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:
        
        "publicKeys": { "type": "STATIC_KEYS", "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:
        
        "publicKeys": { "type": "STATIC_KEYS", "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.
  - 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
  - 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 especificado é levado em consideração quando o gateway de 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.
  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": "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"
      }
    }
  ]
}
```

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

Adicione a seguinte política authorization à seção 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>" ]
        }
      }
    }
  ]
}

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

Adicione uma política de solicitação authorization para todas as rotas restantes na especificação de implantação de API.

Observação

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ê selecionar a opção Carregar uma API 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 de API por meio da Criação de uma Implantação de API e Atualizando um Gateway de API.
(Opcional) Confirme se a API foi implantada com êxito, chamando-a (consulte Chamando uma API Implantada em um Gateway de API).

Exemplo: Migrando uma Política de Solicitação JWT_AUTHENTICATION para uma Política de Solicitação TOKEN_AUTHENTICATION

Esta seção mostra um exemplo de uma política de solicitação JWT_AUTHENTICATION existente migrada para uma política TOKEN_AUTHENTICATION.

Uma maneira de abordar a migração é criar uma política de solicitação TOKEN_AUTHENTICATION vazia e preenchê-la com valores da política de solicitação JWT_AUTHENTICATION

Antes da Migração:

A política de solicitação JWT_AUTHENTICATION original, antes da migração:

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

Após a Migração:

A nova política de solicitação TOKEN_AUTHENTICATION preenchida com valores da política de solicitação JWT_AUTHENTICATION original:

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

Documentação do Oracle Cloud Infrastructure

Validando Tokens para Adicionar Autenticação e Autorização a Implantações de API

O que acontece durante a autenticação de token?

Observações sobre JWTs (JSON Web Tokens)

Observações sobre o OAuth 2.0 e o OpenID Connect

Notas sobre a proteção contra falsificação de solicitações entre locais (CSRF)

Observações sobre o uso de políticas de solicitação JWT_AUTHENTICATION

Pré-requisitos para Autenticação de Token

usando a console para adicionar políticas de solicitação de autenticação e autorização de token

Editar arquivo JSON para adicionar políticas de solicitação de autenticação e autorização de token

Detalhes do Provedor de Identidades a Serem Usados para Reivindicações iss e aud e para o URI JWKS

Parâmetros de Chave Necessários para Verificar Assinaturas de JWT

Usando uma Política de Solicitação de Autenticação JWT_AUTHENTICATION (não mais recomendada)

Exemplo: Migrando uma Política de Solicitação JWT_AUTHENTICATION para uma Política de Solicitação TOKEN_AUTHENTICATION

Antes da Migração:

Após a Migração: