Adicionando Vários Servidores de Autenticação à mesma Implantação de API

Um requisito comum é autenticar solicitações enviadas para a mesma implantação de API de maneiras diferentes. Por exemplo, talvez você queira que uma solicitação de entrada de um cliente de API seja enviada para uma função de autorizador para autenticação. Enquanto isso, talvez você queira que um JWT (JSON Web Token) incluído em uma solicitação de entrada de outro cliente de API seja validado com um provedor de identidades. Por conveniência, esses diferentes tipos de autenticação e autorização (função de autorizador, autenticação JWT) são chamados de "servidores de autenticação".

Para atender ao requisito de autenticar solicitações enviadas a uma implantação de API de diferentes maneiras, você pode definir vários servidores de autenticação para a mesma implantação de API. Os servidores de autenticação configurados podem ser do mesmo tipo ou de um tipo diferente. É possível especificar os seguintes tipos de servidor de autenticação:

Ao definir vários servidores de autenticação para a mesma implantação de API, você cria regras para permitir que o gateway de API selecione dinamicamente qual servidor de autenticação usar para autenticar solicitações, com base em um elemento na solicitação original.

Para permitir que o gateway de API selecione dinamicamente o servidor de autenticação correto, use as seguintes variáveis de contexto para capturar elementos da solicitação:

  • request.auth[<key>] em que <key> é o nome de uma reivindicação contida em um token JWT.
  • request.headers[<key>] em que <key> é o nome de um cabeçalho incluído na solicitação à API.
  • request.host como o nome do host para o qual a solicitação original foi enviada.
  • request.path[<key>] em que <key> é o nome de um parâmetro de caminho definido na especificação de implantação de API.
  • request.query[<key>] em que <key> é o nome de um parâmetro de consulta incluído na solicitação à API.
  • request.subdomain[<key>] em que <key> é a parte final do nome do host a ser ignorada ao capturar a parte principal do nome do host para a qual a solicitação original foi enviada.

Observe que, se uma variável de contexto tiver vários valores, somente o primeiro valor será usado ao selecionar o servidor de autenticação. Para obter mais informações sobre variáveis de contexto, consulte Adicionando Variáveis de Contexto a Políticas e Definições de Back-End de HTTP.

Você pode configurar vários servidores de autenticação para a mesma implantação de API em uma especificação de implantação de API:

  • Usando a Console.
  • Editando um arquivo JSON.

Observações sobre a correspondência de regras do servidor de autenticação

Ao criar as regras para determinar qual servidor de autenticação usar, você pode especificar o quanto o valor da variável de contexto deve corresponder a um determinado valor para que a solicitação seja roteada para um servidor de autenticação específico. Você pode exigir uma correspondência exata ou especificar um valor que comece com um curinga ou termine com ele. O gateway de API avalia as regras na ordem especificada (regras de correspondência exata primeiro, seguidas de regras curinga) e usa a primeira regra de correspondência. Você também pode especificar uma regra padrão a ser usada se o valor da variável de contexto não corresponder a nenhuma regra do servidor de autenticação. Se nenhuma regra for especificada como padrão e o valor da variável de contexto em uma solicitação de entrada não corresponder a nenhuma regra do servidor de autenticação, a solicitação retornará um erro. A ordem de precedência para determinar qual regra de servidor de autenticação (e, portanto, qual servidor de autenticação) usar pode ser resumida como:

  • Se o valor da variável de contexto corresponder exatamente ao valor de uma regra, use essa regra.
  • Caso contrário, se o valor da variável de contexto corresponder ao valor de uma regra que começa ou termina com um curinga, use a primeira regra que contém um curinga correspondente.
  • Caso contrário, se uma regra for especificada como a regra padrão, use essa regra.
  • Caso contrário, retorne uma resposta de erro 401 Unauthorized.

Usando a Console para Adicionar Vários Servidores de Autenticação à mesma Implantação de API

Para adicionar vários servidores de autenticação para a mesma implantação de API a uma especificação de implantação de API usando a Console:

  1. 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.

  2. Selecione Próximo para exibir a página Autenticação.
  3. Selecione Multiautenticação para especificar que você deseja que as solicitações de autenticação sejam roteadas para diferentes servidores de autenticação, de acordo com a variável de contexto e as regras informadas:
    1. Na lista Seletor, selecione a tabela de contexto (que contém a variável de contexto) a ser usada ao determinar o servidor de autenticação para o qual enviar a solicitação de autenticação, da seguinte forma:
      • Autenticação: Use o valor de uma reivindicação contida em um JWT (e salva na tabela de contexto request.auth) para determinar o servidor de autenticação. Observe que, se você selecionar Autenticação, deverá especificar servidores de autenticação do tipo JSON Web Token (JWT) para todas as regras do servidor de autenticação na implantação de API. Se você selecionar Autenticação na lista Seletor, observe também que o local dos JWTs deve ser o mesmo para todos os servidores de autenticação JSON Web Token (JWT) (o mesmo cabeçalho de solicitação e esquema de autorização ou o mesmo parâmetro de consulta).
      • Cabeçalhos: Use o valor de um cabeçalho da solicitação original (e salvo na tabela de contexto request.headers) para determinar o servidor de autenticação.
      • Host: Use o nome do host para o qual a solicitação original foi enviada (extraído do campo do host do cabeçalho do Host na solicitação e salvo na tabela de contexto request.host) para determinar o servidor de autenticação.
      • Caminho: Use um parâmetro de caminho da solicitação original (e salvo na tabela de contexto request.path) para determinar o servidor de autenticação.
      • Parâmetros de consulta: Use o valor de um parâmetro de consulta da solicitação original (e salvo na tabela de contexto request.query) para determinar o servidor de autenticação.
      • Subdomínio: Use a parte inicial do nome do host para a qual a solicitação original foi enviada (apenas essa parte do nome do host não especificada como a chave e salva na tabela de contexto request.subdomain) para determinar o servidor de autenticação. Observe que a chave é a parte final do nome do host a ser usado.
    2. Dependendo da tabela de contexto selecionada, informe o nome da chave a ser usada ao determinar o servidor de autenticação para o qual a solicitação de autenticação será enviada.
  4. Selecione Definir Política para informar uma regra para a variável de contexto que, se atendida, roteia a solicitação de autenticação para o servidor de autenticação definido.
  5. Informe os detalhes da regra do servidor de autenticação da seguinte forma:
    • Nome: Informe um nome para a regra do servidor de autenticação. Use o nome informado para identificar o servidor de autenticação ao fazer referência a logs e métricas. O nome deve ser exclusivo em todas as regras do servidor de autenticação definidas para a implantação de API.
    • Tipo de correspondência: Especifique o quanto o valor da variável de contexto deve corresponder a um valor informado para que a solicitação seja roteada para este servidor de autenticação. Selecione Qualquer um de se a variável de contexto tiver que corresponder exatamente ao valor no campo Valores. Selecione Curinga se a variável de contexto tiver que corresponder a um valor no campo Expressão que contenha curingas. A correspondência de valor não faz distinção entre maiúsculas e minúsculas se você selecionar Qualquer um de e faz distinção entre maiúsculas e minúsculas se selecionar Curinga.
    • Valores: (Exibido se você tiver selecionado Qualquer um de no campo Tipo de correspondência.) Especifique um valor (ou vários valores em uma lista separada por vírgulas) que a variável de contexto deve corresponder exatamente. Observe que a correspondência não fará distinção entre maiúsculas e minúsculas se você tiver selecionado Qualquer um de. Observe também que os valores devem ser exclusivos em uma única regra de servidor de autenticação e em todas as regras do servidor de autenticação definidas para a implantação de API.
    • Expressão: (Exibido se você selecionou Curinga no campo Tipo de correspondência) Especifique um valor começando com, ou terminando com, um curinga que a variável de contexto deve corresponder. Use o curinga * (asterisco) para indicar zero ou mais caracteres e/ou o curinga + (sinal de mais) para indicar um ou mais caracteres. Observe que a correspondência fará distinção entre maiúsculas e minúsculas se você tiver selecionado Curinga. Observe que você não pode incluir mais de um curinga em um valor e não pode incluir um curinga no meio de um valor.
    • Tornar padrão: Especifique se deseja usar o servidor de autenticação definido para esta regra se nenhuma outra regra do servidor de autenticação corresponder ao valor da variável de contexto. Você só pode especificar uma regra de servidor de autenticação como padrão para uma implantação de API. Se nenhuma regra for marcada como padrão e o valor da variável de contexto em uma solicitação recebida não corresponder a nenhuma regra do servidor de autenticação definida para uma implantação de API, a solicitação retornará uma resposta de erro 401 Unauthorized.
  6. 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.

  7. Informe os detalhes do servidor de autenticação da seguinte forma:
    1. No campo Tipo de autenticação, selecione JSON Web Token (JWT) ou Função do autorizador como o servidor de autenticação para o qual rotear a solicitação de autenticação se a regra informada for atendida.

      Observe que, se você tiver selecionado Autenticação na lista Seletor, deverá selecionar JSON Web Token (JWT) como o tipo de servidor de autenticação. Se você selecionou Autenticação na lista Seletor, observe também que o local dos JWTs deve ser o mesmo para todos os servidores de autenticação JSON Web Token (JWT) (o mesmo cabeçalho de solicitação e esquema de autorização ou o mesmo parâmetro de consulta).

    2. Informe os detalhes do servidor de autenticação selecionado. Os detalhes a serem informados dependerão do tipo de servidor de autenticação selecionado:
    3. Selecione Definir para criar o servidor de autenticação e a regra associada.
  8. Opcionalmente, selecione Definir política novamente para definir servidores de autenticação adicionais e regras associadas.
  9. Selecione Próximo para informar detalhes de rotas individuais na implantação de API na página Rotas.
  10. Selecione Salvar Alterações e, em seguida, selecione Próximo para revisar os detalhes informados para a implantação de API.
  11. Selecione Criar ou Salvar Alterações para criar ou atualizar a implantação de API.
  12. (Opcional) Confirme se a API foi implantada com êxito, chamando-a (consulte Chamando uma API Implantada em um Gateway de API).

Editando um Arquivo JSON para Adicionar Vários Servidores de Autenticação à mesma Implantação de API

Para adicionar vários servidores de autenticação para a mesma implantação de API a uma especificação de implantação de API em um arquivo JSON:

  1. Usando seu editor de JSON preferido, crie uma nova especificação de implantação de API (consulte Criando uma Especificação de Implantação de API) no formato:

    {
      "requestPolicies": {
        "dynamicAuthentication": {
          "selectionSource": {
            "selector": "<context-table-key>",
            "type": "SINGLE"
          },
          "authenticationServers": [
            {
              "key": {
                "type": "<ANY_OF|WILDCARD>",
                "values": ["<context-variable-value>"],
                "isDefault": "<true|false>",
                "name": "<rule-name>"
              },
              "authenticationServerDetail": {
                "type": "<authentication-server-type>",
                "<auth-server-attribute-name>": "<auth-server-attribute-value>",
                ...
                "<auth-server-attribute-name>": "<auth-server-attribute-value>"
              }
            }
          ]
        }
      },
      "routes": []
    }

    em que:

    • "dynamicAuthentication" especifica que você deseja que o gateway de API selecione dinamicamente qual servidor de autenticação usar para autenticar solicitações, com base em um elemento na solicitação.
    • "selector": "<context-table-key>" especifica a tabela de contexto (e a chave, se apropriado) a partir da qual obter o valor da variável de contexto que determina o servidor de autenticação para o qual enviar solicitações de autenticação, da seguinte forma:
      • request.auth[<key>] Use o valor de uma reivindicação contida em um JWT (JSON Web Token) para determinar o servidor de autenticação. <key> é o nome da reivindicação. Por exemplo, request.auth[tenant]. Observe que, se você especificar request.auth[<key>], deverá especificar servidores de autenticação do tipo JWT_AUTHENTICATION para todas as regras do servidor de autenticação na implantação de API. Se você especificar request.auth[<key>], observe também que o local dos JWTs deve ser o mesmo para todos os servidores de autenticação (o mesmo cabeçalho de solicitação e esquema de autorização ou o mesmo parâmetro de consulta).
      • request.headers[<key>] Use o valor de um cabeçalho da solicitação original para determinar o servidor de autenticação. <key> é o nome do cabeçalho. Por exemplo, request.headers[Accept]
      • request.host Use o nome do host para o qual a solicitação original foi enviada (extraída do campo do host do cabeçalho do Host na solicitação) para determinar o servidor de autenticação.
      • request.path[<key>] Use um parâmetro de caminho da solicitação original para determinar o servidor de autenticação. <key> é o nome do parâmetro de caminho. Por exemplo, request.path[region]
      • request.query[<key>] Use o valor de um parâmetro de consulta da solicitação original para determinar o servidor de autenticação. <key> é o nome do parâmetro de consulta. Por exemplo, request.query[state]
      • request.subdomain[<key>] Use a parte inicial do nome do host para a qual a solicitação original foi enviada (apenas essa parte do nome do host não especificada como chave) para determinar o servidor de autenticação. Observe que <key> é a parte final do nome do host a não ser usada. Por exemplo, request.subdomain[example.com]
    • "type": "SINGLE" especifica que você deseja usar uma única variável de contexto para selecionar dinamicamente o servidor de autenticação.
    • "key": {...} especifica a regra que deve ser atendida para enviar uma solicitação ao servidor de autenticação especificado por "authenticationServerDetail": {…}.
    • "type": "<ANY_OF|WILDCARD>" especifica o quanto o valor da variável de contexto identificada por <context-table-key> deve corresponder ao valor informado para <context-variable-value> para que a solicitação seja enviada ao servidor de autenticação especificado por "authenticationServerDetail": {…}. Especifique ANY_OF se o valor da variável de contexto identificado por <context-table-key> deve corresponder exatamente ao valor especificado para <context-variable-value>. Especifique WILDCARD se o valor da variável de contexto identificado por <context-table-key> deve corresponder a um valor contendo curingas que você especifica para <context-variable-value>. A correspondência de valor não fará distinção entre maiúsculas e minúsculas se você especificar ANY_OF e fará distinção entre maiúsculas e minúsculas se especificar WILDCARD.
    • <context-variable-value> é um valor que possivelmente corresponde ao valor da variável de contexto identificada por <context-table-key>. Você pode incluir várias entradas "<context-variable-value>" no array values:[...], separadas por vírgulas. A solicitação será enviada ao servidor de autenticação especificado por "authenticationServerDetail": {…} se os valores corresponderem, da seguinte forma:
      • Se você especificou "type": "ANY_OF", os valores deverão corresponder exatamente. Observe que os valores devem ser exclusivos em uma única regra de servidor de autenticação e em todas as regras de servidor de autenticação definidas para uma implantação de API. A correspondência de valor não fará distinção entre maiúsculas e minúsculas se você tiver especificado ANY_OF.
      • Se você especificou "type": "WILDCARD", poderá especificar um valor para <context-variable-value> que comece com um curinga ou termine com ele. Use o curinga * (asterisco) para indicar zero ou mais caracteres e/ou o curinga + (sinal de mais) para indicar um ou mais caracteres. Observe que não é possível incluir mais de um curinga em um valor e não é possível incluir um curinga no meio de um valor. A correspondência de valor fará distinção entre maiúsculas e minúsculas se você tiver especificado WILDCARD.
      Por exemplo, se quiser que uma solicitação de um cliente de API que possa aceitar uma resposta xml (conforme indicado no cabeçalho Aceitar da solicitação) seja roteada para um servidor de autenticação específico, você poderá especificar:
      • "selector": "request.headers[Accept]"
      • "type": "ANY_OF"
      • "values": ["application/xml"]
    • "isDefault": "<true|false>" é um valor booliano opcional (true ou false) que indica se o servidor de autenticação deve ser usado para essa regra se nenhuma outra regra do servidor de autenticação corresponder ao valor da variável de contexto. Se não for especificado, "isDefault": "false" será assumido. Você só pode especificar uma regra de servidor de autenticação como padrão para uma implantação de API. Se nenhuma regra for marcada como padrão e o valor da variável de contexto em uma solicitação de entrada não corresponder a nenhuma regra do servidor de autenticação definida para uma implantação de API, a solicitação retornará uma resposta de erro 401 Unauthorized.
    • "name": "<rule-name>" especifica um nome para a regra. Use esse nome para identificar o servidor de autenticação ao fazer referência a logs e métricas. O nome deve ser exclusivo em todas as regras do servidor de autenticação definidas para a implantação de API.
    • "type": "<authentication-server-type>" especifica o tipo do servidor de autenticação. Os valores válidos são JWT_AUTHENTICATION e CUSTOM_AUTHENTICATION. Observe que, se você tiver especificado request.auth[<key>], deverá especificar servidores de autenticação do tipo JWT_AUTHENTICATION para todas as regras do servidor de autenticação na implantação de API. Se você especificou request.auth[<key>], observe também que o local dos JWTs deve ser o mesmo para todos os servidores de autenticação (o mesmo cabeçalho de solicitação e esquema de autorização ou o mesmo parâmetro de consulta).
    • "<auth-server-attribute-name>": "<auth-server-attribute-value>" são atributos e valores de atributo para o tipo de servidor de autenticação especificado. Os atributos e os valores de atributo a serem informados dependerão do tipo de servidor de autenticação especificado:

    Por exemplo, a especificação de implantação de API a seguir inclui a seleção do servidor de autenticação dinâmica que trata solicitações de autenticação com base no valor do parâmetro de consulta vehicle-type informado na solicitação. Para obter uma explicação mais detalhada deste exemplo, consulte Exemplo 1: Selecionar JWT ou função sem servidor como servidor de autenticação usando um parâmetro de consulta (incluindo seleção de curinga e padrão).

    {
      "requestPolicies": {
        "dynamicAuthentication": {
          "selectionSource": {
            "selector": "request.query[vehicle-type]",
            "type": "SINGLE"
          },
          "authenticationServers": [
            {
              "key": {
                "type": "ANY_OF",
                "values": ["car"],
                "isDefault": "true",
                "name": "authServer1"
              },
              "authenticationServerDetail": {
                "type": "JWT_AUTHENTICATION",
                "tokenHeader": "Authorization",
                "tokenAuthScheme": "Bearer",
                "isAnonymousAccessAllowed": true,
                "issuers": ["https://recommend-app.eu.auth0.com/"],
                "audiences": ["api.dev.io"],
                "maxClockSkewInSeconds": 0,
                "verifyClaims": [
                  {
                    "key": "gty",
                    "value": ["client-credentials"],
                    "isRequired": true
                  }
                ],
                "publicKeys": {
                  "type": "REMOTE_JWKS",
                  "uri": "https://recommend-app.eu.auth0.com/.well-known/jwks.json",
                  "maxCacheDurationInHours": 1
                }
              }
            },
            {
              "key": {
                "type": "WILDCARD",
                "expression": "mini*",
                "name": "authServer2"
              },
              "authenticationServerDetail": {
                "type": "CUSTOM_AUTHENTICATION",
                "functionId": "ocid1.fnfunc.oc1.iad.aaaaaaaaac______dfa",
                "isAnonymousAccessAllowed": true
              }
            }
          ]
        }
      },
      "routes": []
    }
  2. Salve o arquivo JSON que contém a especificação de implantação de API.
  3. 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 Fazer upload de 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.

  4. (Opcional) Confirme se a API foi implantada com êxito, chamando-a (consulte Chamando uma API Implantada em um Gateway de API).

Exemplos

Exemplo 1: Selecione a função JWT ou sem servidor como servidor de autenticação usando um parâmetro de consulta (incluindo seleção de curinga e padrão)

Neste exemplo, o gateway de API determina o servidor de autenticação para o qual enviar a solicitação de autenticação com base no valor do parâmetro de consulta vehicle-type informado na solicitação. Se o parâmetro de consulta vehicle-type tiver o valor car, o JWT no cabeçalho de autorização da solicitação será validado recuperando chaves de verificação públicas do provedor de identidades https://recommend-app.eu.auth0.com. Se o parâmetro de consulta vehicle-type tiver um valor que comece com mini, uma solicitação de autenticação será enviada para uma função sem servidor no OCI Functions para processamento. Se o valor do parâmetro de consulta vehicle-type não for car nem mini*, o gateway de API assumirá, por padrão, que há um JWT no cabeçalho de autorização da solicitação e tentará validá-lo recuperando chaves de verificação públicas do provedor de identidades https://recommend-app.eu.auth0.com:

{
  "requestPolicies": {
    "dynamicAuthentication": {
      "selectionSource": {
        "selector": "request.query[vehicle-type]",
        "type": "SINGLE"
      },
      "authenticationServers": [
        {
          "key": {
            "type": "ANY_OF",
            "values": ["car"],
            "isDefault": "true",
            "name": "authServer1"
          },
          "authenticationServerDetail": {
            "type": "JWT_AUTHENTICATION",
            "tokenHeader": "Authorization",
            "tokenAuthScheme": "Bearer",
            "isAnonymousAccessAllowed": true,
            "issuers": ["https://recommend-app.eu.auth0.com/"],
            "audiences": ["api.dev.io"],
            "maxClockSkewInSeconds": 0,
            "verifyClaims": [
              {
                "key": "gty",
                "value": ["client-credentials"],
                "isRequired": true
              }
            ],
            "publicKeys": {
              "type": "REMOTE_JWKS",
              "uri": "https://recommend-app.eu.auth0.com/.well-known/jwks.json",
              "maxCacheDurationInHours": 1
            }
          }
        },
        {
          "key": {
            "type": "WILDCARD",
            "expression": "mini*",
            "name": "authServer2"
          },
          "authenticationServerDetail": {
            "type": "CUSTOM_AUTHENTICATION",
            "functionId": "ocid1.fnfunc.oc1.iad.aaaaaaaaac______dfa",
            "isAnonymousAccessAllowed": true
          }
        }
      ]
    }
  },
  "routes": []
}

Exemplo 2: Selecione o servidor de autenticação JWT usando reivindicações de tokens JWT

Neste exemplo, o gateway de API determina o servidor de autenticação para o qual enviar a solicitação de autenticação com base na reivindicação tenant em um token JWT passado no cabeçalho de Autorização da solicitação. Dois exemplos de tokens JWT seguem a especificação de implantação de API:

{
  "pathPrefix": "/deployment-path",
  "specification": {
    "requestPolicies": {
      "dynamicAuthentication": {
        "selectionSource": {
          "selector": "request.auth[tenant]",
          "type": "SINGLE"
        },
        "authenticationServers": [
          {
            "key": {
              "values": ["cars"],
              "type": "ANY_OF",
              "name": "authServer1"
            },
            "authenticationServerDetail": {
              "type": "JWT_AUTHENTICATION",
              "tokenHeader": "Authorization",
              "tokenAuthScheme": "Bearer",
              "isAnonymousAccessAllowed": true,
              "issuers": ["https://tenant-2.us.auth0.com/"],
              "audiences": ["https://tenant-2"],
              "maxClockSkewInSeconds": 0,
              "verifyClaims": [
                {
                  "key": "gty",
                  "value": ["client-credentials"],
                  "isRequired": true
                }
              ],
              "publicKeys": {
                "type": "REMOTE_JWKS",
                "uri": "https://car.us.auth0.com/.well-known/jwks.json",
                "maxCacheDurationInHours": 1
              }
            }
          },
          {
            "key": {
              "values": ["trucks"],
              "type": "ANY_OF",
              "name": "authServer2"
            },
            "authenticationServerDetail": {
              "type": "JWT_AUTHENTICATION",
              "tokenHeader": "Authorization",
              "tokenAuthScheme": "Bearer",
              "isAnonymousAccessAllowed": true,
              "issuers": ["https://tenant-2.us.auth0.com/"],
              "audiences": ["https://tenant-2"],
              "maxClockSkewInSeconds": 0,
              "verifyClaims": [
                {
                  "key": "gty",
                  "value": ["client-credentials"],
                  "isRequired": true
                }
              ],
              "publicKeys": {
                "type": "REMOTE_JWKS",
                "uri": "https://truck.us.auth0.com/.well-known/jwks.json",
                "maxCacheDurationInHours": 1
              }
            }
          }
        ]
      }
    }
  },
  "loggingPolicies": {},
  "routes": []
}

Ao autenticar uma solicitação que tenha o token JWT a seguir no cabeçalho de Autorização, o gateway de API recupera o Conjunto de Chaves Web JSON (JWKS) para verificar a assinatura de https://car.us.auth0.com/.well-known/jwks.json.

{
  "iss": "https://tenant-2.us.auth0.com/",
  "sub": "aPz45Gbdfy6dgh30sdfER6cgjkhjx8a@clients",
  "aud": "https://tenant-2",
  "iat": 1641282986,
  "exp": 1641369386,
  "azp": "aPz45Gbdfy6dgh30sdfER6cgjkhjx8a",
  "gty": "client-credentials",
  "tenant":"cars"
}

Ao autenticar uma solicitação que tenha o token JWT a seguir no cabeçalho de Autorização, o gateway de API recupera o Conjunto de Chaves Web JSON (JWKS) para verificar a assinatura de https://truck.us.auth0.com/.well-known/jwks.json.

{
  "iss": "https://tenant-2.us.auth0.com/",
  "sub": "aPz45Gbdfy6dgh30sdfER6cgjkhjx8a@clients",
  "aud": "https://tenant-2",
  "iat": 1641282986,
  "exp": 1641369386,
  "azp": "aPz45Gbdfy6dgh30sdfER6cgjkhjx8a",
  "gty": "client-credentials",
  "tenant":"trucks"
}