Todos os produtos
Search
Central de documentação

API Gateway:Autenticação e autorização de consumidores

Última atualização: Jun 27, 2026

O Cloud-native API Gateway oferece suporte a autenticação global, autenticação no nível de rota e autorização de consumidores. Este tópico descreve como configurar cada método de autenticação e autorizar consumidores a acessar rotas e APIs específicas.

Contexto

A autenticação global é adequada para cenários B2C, como logon unificado. A autenticação de consumidores para rotas e APIs atende a cenários B2B, como a concessão de acesso a APIs para parceiros.

Item

Autenticação global

Autenticação de rota e autorização de consumidor

Casos de uso

Cenários B2C, como autenticação de logon unificado.

Cenários B2B, como concessão de acesso a APIs para parceiros.

Diferença principal

A autorização é ativada automaticamente ao ativar a autenticação.

Após ativar a autenticação, configure a autorização separadamente.

Caminho de configuração

Instance > Security Management > Global Authentication.

  1. API Management > HTTP API Details > Route Management > Policy Configuration > Consumer Authentication.

  2. API Management > WebSocket API Details > Route Management > Policy Configuration > Consumer Authentication.

  3. API Management > REST API Details > Attach Policy > Consumer Authentication.

  4. Consumers > Consumer Details > Consumer Authorization.

Configuração do método de autenticação (exemplo de autenticação JWT)

  1. Ao criar uma configuração, forneça a configuração global de JWKS.

  2. Insira os campos issue e sub para verificar o JWT.

  1. Ao criar uma configuração de consumidor, forneça a configuração de JWKS correspondente para esse consumidor.

  2. Forneça um identificador de consumidor para verificar se o JWT pertence ao consumidor correto. Por padrão, este é o campo uid no payload, mas é possível personalizá-lo.

Configuração do método de autorização

Ao criar uma configuração, forneça uma lista de Domain Name e Path para uma lista de bloqueios ou lista de permissões.

  • Blacklist Mode: solicitações para um Domain Name e Path presentes na lista exigem autenticação. As demais solicitações não exigem.

  • Whitelist Mode: solicitações para um domínio e Path presentes na lista não exigem autenticação. As demais solicitações devem ser autenticadas.

  1. Nas configurações de Configure Policy de uma rota ou API, ative a Authentication.

  2. Em Consumer Authorization, conceda ao consumidor acesso à rota ou API autenticada para concluir o processo de autorização.

Observações de uso

Após ativar a autenticação de consumidor, a política entra em vigor imediatamente. Se nenhum consumidor ou regra de autorização estiver configurado para uma rota ou API publicada, o gateway negará todas as solicitações por padrão.

Uso de autenticação e autorização de consumidores

Autenticação JWT

Fluxo de trabalho da autenticação JWT

  1. O cliente envia uma solicitação de autenticação ao gateway, geralmente com o nome de usuário e a senha do usuário final.

  2. O gateway encaminha a solicitação ao serviço de backend.

  3. O backend valida as credenciais. Após a validação bem-sucedida, gera um token com uma chave privada e o retorna ao gateway.

  4. O gateway retorna o token ao cliente, que o armazena em cache localmente.

  5. O cliente envia uma solicitação de negócio com o token em cache para o gateway.

  6. O gateway verifica o token usando a chave pública configurada. Se for válido, encaminha a solicitação ao backend.

  7. O backend processa a solicitação e retorna uma resposta.

  8. O gateway encaminha a resposta ao cliente.

As seções a seguir descrevem como gerar um token, enviar uma solicitação ao gateway e validar o token usando a chave pública configurada.

Gerar um token

O exemplo Java a seguir mostra como gerar um token. É possível usar ferramentas semelhantes em outras linguagens.

  1. Crie um projeto Maven e adicione a dependência.

    Adicione a seguinte dependência ao projeto:

    <dependency>
        <groupId>org.bitbucket.b_c</groupId>
        <artifactId>jose4j</artifactId>
        <version>0.7.0</version>
    </dependency>
  2. Escolha um método para gerar o token.

    É possível gerar um token usando uma chave simétrica ou assimétrica.

    Chave simétrica

    Código de exemplo:

    package org.example;
    
    import java.io.UnsupportedEncodingException;
    import java.security.PrivateKey;
    
    import org.jose4j.base64url.Base64;
    import org.jose4j.json.JsonUtil;
    import org.jose4j.jwk.OctJwkGenerator;
    import org.jose4j.jwk.OctetSequenceJsonWebKey;
    import org.jose4j.jws.AlgorithmIdentifiers;
    import org.jose4j.jws.JsonWebSignature;
    import org.jose4j.jwt.JwtClaims;
    import org.jose4j.jwt.NumericDate;
    import org.jose4j.keys.HmacKey;
    import org.jose4j.lang.JoseException;
    import sun.lwawt.macosx.CSystemTray;
    
    public class Main {
        public static void main(String[] args) throws JoseException, UnsupportedEncodingException {
            // Use the example from this topic.
            String privateKeyJson = "{\n"
                    + "    \"k\": \"VoBG-oyqVoyCr9G56ozmq8n_rlDDyYMQOd_DO4GOkEY\",\n"
                    + "    \"kty\": \"oct\",\n"
                    + "    \"alg\": \"HS256\",\n"
                    + "}";
            JwtClaims claims = new JwtClaims();
            claims.setGeneratedJwtId();
            claims.setIssuedAtToNow();
            // Set the expiration time to less than 7 days.
            NumericDate date = NumericDate.now();
            date.addSeconds(120*60);
            claims.setExpirationTime(date);
            claims.setNotBeforeMinutesInThePast(1);
            // Add custom parameters. All values must be of the String type.
            // Set the consumer identifier.
            claims.setClaim("uid", "11215ac069234abcb8944232b79ae711");
            JsonWebSignature jws = new JsonWebSignature();
            // Set the encryption algorithm.
            jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.HMAC_SHA256);
            jws.setKey(new HmacKey(Base64.decode(JsonUtil.parseJson(privateKeyJson).get("k").toString())));
            jws.setPayload(claims.toJson());
            String jwtResult = jws.getCompactSerialization();
            System.out.println("Generate Json Web token , result is \n " + jwtResult);
        }
    }

    Configurações do código:

    • privateKeyJson: o JWKS usado ao criar o consumidor. Salve o JWKS durante a criação do consumidor ou recupere-o na página de configuração básica do consumidor.

    • Defina o identificador do consumidor. A instrução é claims.setClaim("uid", "11215ac069234abcb8944232b79ae711"). Esse identificador é gerado automaticamente ao criar um consumidor, mas pode ser modificado. Também é possível recuperá-lo na página de configuração básica do consumidor.

    • Defina o algoritmo de criptografia. A instrução é jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.HMAC_SHA256). Esse algoritmo deve corresponder ao algoritmo no JWKS.

      Nota

      Os algoritmos de criptografia suportados incluem ES256, ES384, ES512, RS256, RS384, RS512, PS256, PS384, PS512, HS256, HS384, HS512 e EdDSA.

      Para criptografia simétrica, decodifique o valor de "k".

      jws.setKey(new HmacKey(Base64.decode(JsonUtil.parseJson(privateKeyJson).get("k").toString())));
    • Defina o tempo de expiração. O token deve expirar em até sete dias. Após a expiração, gere um novo token.

      ...
          NumericDate date = NumericDate.now();
          date.addSeconds(120*60);
          claims.setExpirationTime(date);
          claims.setNotBeforeMinutesInThePast(1);
      ...
    • Adicione parâmetros personalizados ao PAYLOAD do JWKS conforme necessário.

    Chave assimétrica

    Código de exemplo:

    package org.example;
    
    import java.security.PrivateKey;
    import org.jose4j.json.JsonUtil;
    import org.jose4j.jws.AlgorithmIdentifiers;
    import org.jose4j.jws.JsonWebSignature;
    import org.jose4j.jwt.JwtClaims;
    import org.jose4j.jwt.NumericDate;
    import org.jose4j.lang.JoseException;
    import org.jose4j.jwk.RsaJsonWebKey;
    
    public class Main {
        public static void main(String[] args) throws JoseException {
            // Sample key in JWK format.
            String privateKeyJson = "{"
                    + "\"kty\":\"RSA\","
                    + "\"n\":\"u-8lR9lyRhu8tl4vRxOl7yfshssx5jRstabc9n4Rxrz102Z7TPFYrXBZHgf67Y0d-zx9tWd5j91WZxLHv4K6VWPN7zEWEQNn3vUg76dPHPzVkZJWziFPS1EvS4a2gRZdrE4nPogaQ72WySVC0yUF2fL0NKeOclD__coCFxn4QQjcDXyu_CUbI_FuDcdw267mVjjylAaFvOZHH0pXsV8m5zXlpc2aiemWYQJD9MtWRcoKlexWMkTwbEqW5-NWAl0Uo202ahDA1NiaQ98Ch4nw6g2E1GvwxxHkbvMuZcs5z8F5Ct_w0IPtvY7ngSyEN-WCU40oj-C5NUCy_73FpXXdWQ\","
                    + "\"e\":\"AQAB\","
                    + "\"d\":\"Uxg1IqSZazg-Y2AXhVTBrJG5egwD3yZU3qiN0IsDbx0DkFoisG2R6PXg4W9j2n7nv7sKVhgPXrXdyys5mIrDuperaVQJzrHzzlgSHQSb7VQ5Vekfanq95a5avAkvTrpF5raTkYl6G3OLZRqNhnA7Oxe6NEHVsOPxnBQignZgFtiBtCSZY4RVH6Dx4jFfBBNMC9ifyLWLpHut7eczvxI412nBkxgtEjSeFe083NlumO_ZYHbijPcQf5zFWPLEj2EvlgbSwhjc-uSAF4OljAyG_DHZYvztEIGMdxMgBHgwtEvCfzS6PeUgvUR-SB7m_L8z4gjz6TlpSYe3CnZqE69KdQ\","
                    + "\"p\":\"9mNw8U_GxbcSknueUeFFSU9wKD9E9P2ZO5RP5d7o3qGUXOfbrH_g5GMH3YJiPBDZs_2BYFrAACOY4YM-QTiXWVs4xS3OeD8AdH3wEXR_3DMEkOez3cNq3Jy3ZJabm7IUnPMIWv5gpIHghcx0YTtM5RabSgexLMKh2-6sB466378\","
                    + "\"q\":\"w0PzXI_8Q5jv15OUq-dV_Z0kp91Icumf6PEERZN4v3i3VolLBnamMiIQiF74ywclKpZmtfOQTfyL41Xj2vbm2Aus6akRsU3NhQlVtIQTzHWUuEQgMIJYDK7--FzEcZORm1qBiEffiWv6U-slyCcLcNDNT-wjMX8BrS4oWHIoCOc\","
                    + "\"dp\":\"fRRiY76yE_EqVn63Eq4ftGXFdEkaQpzzS1GxderBoTO506hI1rtcedTkS0lDgWa0fjE1mqq3SdrIY8NyuT13Z_9tRHxKkrS5EGpWkyXnOuwTZ1SY9P2dpD1SxJfIizPOTxb5qOf2O81LI-F1O18VXD8rultJUIXGEZaKcpO8vpU\","
                    + "\"dq\":\"V6EP_vMzD5b707AMYVURFx7Fi3vX_pHvzJcVBrBW2P6wsGouvDjU_tygtMKCPoL3X_RdJbynfwgeMyihd-ujz0L2F2pjYUF8QP7ecoNvays9UbBpDbwBDbge_pCLLDlAeAqW5PT0UXSew7hcnUVAciGSchKT_Kt1siVrv72DT_M\","
                    + "\"qi\":\"w5fENzxOivbbbUbawAWSuLgWPtvbTKn2XuPzwr_JzZH08-nadWwQFChcvAiCs8V-306TQOh8NfY308QpGDIq-iRfrS7CEePOjRzpHJfsaQ1IFQqzgDZ9VGdJRDlZqRHx0DbqwMlleVKTC6ER6varalbr4lKU-ZPUQLCzj0e4PMs\""
                    + "}";
    
            JwtClaims claims = new JwtClaims();
            claims.setGeneratedJwtId(); // Automatically generate a JTI (JWT ID).
            claims.setIssuedAtToNow();  // Set the issued at time (iat) to the current time.
    
            // Set the expiration time to less than 7 days.
            NumericDate date = NumericDate.now();
            date.addSeconds(120 * 60); // Set expiration to 120 minutes from now.
            claims.setExpirationTime(date);
            claims.setNotBeforeMinutesInThePast(1); // Set the not before (nbf) time to 1 minute in the past.
    
            // Add custom parameters. All values must be of the String type.
            // Set the consumer identifier.
            claims.setClaim("uid", "11215ac069234abcb8944232b79ae711");
    
            JsonWebSignature jws = new JsonWebSignature();
            // Set the encryption algorithm to RSA-SHA256.
            jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.RSA_USING_SHA256);
    
            // Parse the private key and set it in the signer.
            PrivateKey privateKey = new RsaJsonWebKey(JsonUtil.parseJson(privateKeyJson)).getPrivateKey();
            jws.setKey(privateKey);
    
            // Set the payload content.
            jws.setPayload(claims.toJson());
    
            // Generate the JWT.
            String jwtResult = jws.getCompactSerialization();
            System.out.println("Generate Json Web token , result is \n " + jwtResult);
        }
    }
    

    Configurações do código:

    • As configurações para privateKeyJson, o identificador do consumidor e o tempo de expiração são semelhantes às da criptografia simétrica.

      Defina o algoritmo de criptografia usando a instrução jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.RSA_USING_SHA256). Esse algoritmo deve corresponder ao algoritmo no JWKS.

      Para algoritmos de criptografia assimétrica, use a chave privada para criptografia.

      ...
          jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.RSA_USING_SHA256);
          PrivateKey privateKey = new RsaJsonWebKey(JsonUtil.parseJson(privateKeyJson)).getPrivateKey();
          jws.setKey(privateKey);
      ...
    • Adicione parâmetros personalizados ao PAYLOAD do JWT.

Enviar solicitações de negócio

O Cloud-native API Gateway permite passar o token em um cabeçalho de solicitação. É possível personalizar o nome do cabeçalho e o prefixo do token. A chave e o prefixo na solicitação devem corresponder aos configurados no método de autenticação do consumidor.

  • Solicitações sem JWT retornam um erro 401.

    curl  http://xxx.hello.com/test
  • Solicitações com JWT inválido retornam um erro 401.

    curl  http://xxx.hello.com/test -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyMyJ9.eyJpc3MiOiJhYmNkIiwic3ViIjoidGVzdCIsImlhdCI6MTY2NTY2MDUyNywiZXhwIjoxODY1NjczODE5fQ.-vBSV0bKeDwQcuS6eeSZN9dLTUnSnZVk8eVCXdooCQ1'
  • Se uma solicitação incluir um JWT válido, mas o consumidor não estiver autorizado para a API ou rota, o sistema retornará um erro 403.

    # consumer1 is not authorized for the route or API at the specified path.
    
    curl  'http://xxx.example.com/test' -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyMyJ9.eyJpc3MiOiJhYmNkIiwic3ViIjoidGVzdCIsImlhdCI6MTY2NTY2MDUyNywiZXhwIjoxODY1NjczODE5fQ.-vBSV0bKeDwQcuS6eeSZN9dLTUnSnZVk8eVCXdooCQ4'

Validação de token no servidor

A validação de token possui três etapas:

  1. Verifique se a solicitação inclui um token. Caso contrário, rejeite com 401.

  2. Verifique a validade e a expiração do token usando a chave pública do JWKS do consumidor. Se for inválido ou expirado, rejeite com 401.

  3. Verifique se o consumidor tem autorização para acessar a API ou rota solicitada.

Códigos de erro comuns

Código de status HTTP

Mensagem de erro

Descrição

401

Jwt missing

O JWT está ausente no cabeçalho da solicitação.

401

Jwt expired

O JWT expirou.

401

Jwt verification fails

Falha na verificação do payload do JWT, por exemplo, devido a uma incompatibilidade de iss.

403

Access Denied

Sem permissão para acessar a rota atual.

Autenticação AK/SK (HMAC)

Geração de assinatura no lado do cliente

O cliente gera uma assinatura em três etapas:

  1. Extraia a string a ser assinada: extraia dados essenciais da solicitação original para formar uma string para assinatura.

  2. Crie a assinatura: criptografe a string a ser assinada com a SK para produzir a assinatura final.

  3. Adicione a assinatura: adicione todos os cabeçalhos relacionados à assinatura à solicitação HTTP original para formar a solicitação final.

Etapa 1: Extrair a string a ser assinada

Extraia dados essenciais da solicitação HTTP e monte-os em uma string a ser assinada no seguinte formato:

HTTPMethod
Accept
Content-MD5
Content-Type
Date
Headers
PathAndParameters

Esses sete campos constituem a string a ser assinada, separados por caracteres de nova linha (\n). Se o campo Headers estiver vazio, nenhuma nova linha será necessária após ele. Para qualquer outro campo vazio, inclua seu caractere de nova linha. A assinatura diferencia maiúsculas de minúsculas. Cada campo é extraído da seguinte forma:

  • HTTPMethod: o método HTTP, em letras maiúsculas. Exemplo: POST.

  • Accept: o valor do cabeçalho Accept. Pode estar vazio. Recomendamos definir o cabeçalho Accept explicitamente. Se estiver vazio, alguns clientes HTTP definem um valor padrão de */*, o que causa falha na verificação da assinatura.

  • Content-MD5: o valor do cabeçalho Content-MD5. Pode estar vazio. Calcule isso apenas para solicitações com corpo não formulário. O código Java a seguir mostra como calcular o valor de Content-MD5:

    String content-MD5 = Base64.encodeBase64(MD5(bodyStream.getbytes("UTF-8")));
  • Content-Type: o valor do cabeçalho Content-Type. Pode estar vazio.

  • Date: o valor do cabeçalho Date. Se date_offset não estiver ativado, pode estar vazio. Caso contrário, é usado para verificação de deslocamento de tempo.

  • Headers: selecione cabeçalhos específicos para incluir na assinatura. Concatene-os da seguinte forma:

    • Ordene as chaves de cabeçalho alfabeticamente e concatene-as:

      HeaderKey1 + ":" + HeaderValue1 + "\n"\+
      HeaderKey2 + ":" + HeaderValue2 + "\n"\+
      ...
      HeaderKeyN + ":" + HeaderValueN + "\n"
    • Se o valor de um cabeçalho estiver vazio, use HeaderKey+":"+"\n" para a assinatura, mantendo a chave e os dois pontos.

    • Liste as chaves de todos os cabeçalhos assinados no cabeçalho X-Ca-Signature-Headers, separadas por vírgulas.

    • Os seguintes cabeçalhos não são incluídos no cálculo da assinatura: X-Ca-Signature, X-Ca-Signature-Headers, Accept, Content-MD5, Content-Type e Date.

  • PathAndParameters: inclui o caminho, parâmetros de consulta e parâmetros de formulário. Construído da seguinte forma:

    Path + "?" + Key1 + "=" + Value1 + "&" + Key2 + "=" + Value2 + ... "&" + KeyN + "=" + ValueN
    Importante
    • Ordene as chaves dos parâmetros de consulta e de formulário alfabeticamente antes de concatenar.

    • Se os parâmetros de consulta e de formulário estiverem vazios, use o Path diretamente sem ?.

    • Se o valor de um parâmetro estiver vazio, inclua apenas a chave. O sinal de igual (=) não é incluído.

    • Se a consulta ou formulário contiver parâmetros de array (mesma chave, valores diferentes), use o primeiro valor para o cálculo da assinatura.

Etapa 2: Criar a assinatura

Criptografe e codifique a string a ser assinada para produzir a assinatura final. No exemplo a seguir, stringToSign é a string extraída, secret é a SK da configuração AK/SK e sign é a assinatura gerada:

Mac hmacSha256 = Mac.getInstance("HmacSHA256");
byte[] secretBytes = secret.getBytes("UTF-8");
hmacSha256.init(new SecretKeySpec(secretBytes, 0, secretBytes.length, "HmacSHA256"));
byte[] result = hmacSha256.doFinal(stringToSign.getBytes("UTF-8"));
String sign = Base64.encodeBase64String(result);

Decodifique stringToSign em um array de bytes UTF-8, criptografe-o e codifique o resultado em Base64 para produzir a assinatura.

Etapa 3: Adicionar a assinatura à solicitação

Inclua os quatro cabeçalhos a seguir na solicitação HTTP para verificação de assinatura:

  • x-ca-key: a AK da configuração de autenticação AK/SK.

  • x-ca-signature-method: o algoritmo de assinatura. Os valores válidos são HmacSHA256 ou HmacSHA1. Isso é opcional e o padrão é HmacSHA256.

  • x-ca-signature-headers: uma lista separada por vírgulas de todas as chaves de cabeçalho incluídas na assinatura. Isso é opcional.

  • x-ca-signature: a assinatura. Campo obrigatório.

Verificação de assinatura no servidor

A verificação de assinatura no servidor funciona da seguinte maneira:

  1. Extraia a string a ser assinada: extraia dados essenciais da solicitação recebida para formar uma string para assinatura.

  2. Recupere a SK: leia a AK da solicitação e use-a para recuperar a SK correspondente.

  3. Calcule a assinatura: use o mesmo algoritmo de criptografia e a SK recuperada para criptografar a string a ser assinada, produzindo uma assinatura no lado do servidor.

  4. Verifique a assinatura: leia a assinatura do lado do cliente na solicitação e compare-a com a assinatura do lado do servidor para verificar a correspondência.

Solução de problemas

Quando a verificação de assinatura falha, o servidor retorna sua string a ser assinada (StringToSign) no cabeçalho de resposta X-Ca-Error-Message. Compare a StringToSign do servidor com aquela calculada localmente. Se coincidirem, verifique se você usou a SK correta. Como os cabeçalhos HTTP não podem conter caracteres de nova linha, as novas linhas na StringToSign são substituídas por #:

X-Ca-Error-Message:  Server StringToSign:`GET#application/json##application/json##X-Ca-Key:200000#X-Ca-Timestamp:1589458000000#/app/v1/config/keys?keys=TEST`

Códigos de erro relacionados

Código de status HTTP

Mensagem de erro

Descrição

401

Invalid Key

O cabeçalho x-ca-key está ausente ou a chave é inválida.

401

Empty Signature

O cabeçalho x-ca-signature está ausente.

400

Invalid Signature

A assinatura no cabeçalho x-ca-signature não corresponde à assinatura calculada pelo servidor.

400

Invalid Content-MD5

O cabeçalho Content-MD5 está incorreto.

400

Invalid Date

O deslocamento de tempo calculado a partir do cabeçalho Date excede o date_offset configurado.

413

Request Body Too Large

O tamanho do corpo da solicitação excede o limite de 32 MB.

413

Payload Too Large

O corpo da solicitação excede os DownstreamConnectionBufferLimits configurados globalmente.

403

Unauthorized Consumer

O chamador da solicitação não está autorizado.

Código de exemplo (Go)

go
package main
import (
	"bytes"
	"crypto/hmac"
	"crypto/md5"
	"crypto/sha256"
	"encoding/base64"
	"fmt"
	"io"
	"net/http"
	"strings"
	"time"
)
func generateHMACSignature(toSign string, key string) (string, error) {
	h := hmac.New(sha256.New, []byte(key))
	h.Write([]byte(toSign))
	return base64.StdEncoding.EncodeToString(h.Sum(nil)), nil
}
func test(accessKey, secretKey string) {
	body := `{"hello":"world"}`
	h := md5.New()
	h.Write([]byte(body))
	payload := base64.StdEncoding.EncodeToString(h.Sum(nil))
	headers := map[string]string{
		"accept":                 "application/json",
		"content-type":           "application/json",
		"date":                   time.Now().Format("2006-01-02 15:04:05"),
		"x-ca-key":               accessKey,
		"foo":                    "bar",
		"x-ca-signature-headers": "foo",
		"content-md5":            payload,
	}
	sts := strings.Join([]string{"POST", headers["accept"], headers["content-md5"], headers["content-type"], headers["date"], "foo:bar", "/post"}, "\n")
	fmt.Printf("String to sign is: %s\n", strings.ReplaceAll(sts, "\n", "#"))
	sign, _ := generateHMACSignature(sts, secretKey)
	fmt.Printf("Signed string is: %s\n", sign)
	headers["x-ca-signature"] = sign
	req, _ := http.NewRequest("POST", "http://localhost:8080/post", bytes.NewBufferString(body))
	for k, v := range headers {
		req.Header.Add(k, v)
	}
	client := &http.Client{}
	resp, err := client.Do(req)
	if err != nil {
		fmt.Println("read body error")
	}
	defer resp.Body.Close()
	fmt.Println("Headers are as follows:")
	for k, v := range resp.Header {
		// If signature verification fails, the X-Ca-Error-Message response header
		// contains the server-side string to sign, which can be used for troubleshooting.
		fmt.Printf("  %s: %s\n", k, v)
	}
	respBody, _ := io.ReadAll(resp.Body)
	fmt.Println(string(respBody))
}
func main() {
	test("appKey", "appSecret")
}

Autenticação por chave de API

O gateway autentica solicitações com base na origem de credencial configurada. O processo é semelhante para APIs e rotas. Os exemplos a seguir usam rotas.

Três tipos de origem de credencial estão disponíveis para chaves de API:

  1. Origem de credencial padrão: Authorization: Bearer <token>.

  2. Cabeçalho personalizado: forneça um nome de cabeçalho.

  3. Parâmetro de consulta personalizado: forneça um nome de parâmetro de consulta.

Origem de credencial padrão

Suponha que uma solicitação corresponda à rota abc. A chave de API é fornecida no cabeçalho Authorization com o prefixo Bearer (observe o espaço à direita).

curl  http://xxx.test.com/test -H 'Authorization: Bearer 2bda943c-ba2b-11ec-ba07-00163e1250b5'

Defina a chave de API no cabeçalho da solicitação

curl  http://xxx.test.com/test -H 'x-api-key: 2bda943c-ba2b-11ec-ba07-00163e1250b5'

Origem de cabeçalho personalizado

Suponha que a solicitação corresponda à rota abc e a chave de API esteja em um cabeçalho personalizado.

  • Se a chave de API estiver no local errado (por exemplo, como parâmetro de consulta em vez do cabeçalho personalizado configurado), a solicitação será negada com 401.

    curl  http://xxx.test.com/test?apikey=2bda943c-ba2b-11ec-ba07-00163e1250b5
  • Se a política estiver ativada, mas o consumidor não estiver autorizado, a solicitação será negada com 403.

    curl  http://xxx.test.com/test -H 'x-api-key: 2bda943c-ba2b-11ec-ba07-00163e1250b5'

Parâmetro de consulta personalizado

Suponha que a solicitação corresponda à rota abc e a chave de API esteja em um parâmetro de URL.

  • Se a autenticação de consumidor não estiver ativada para a rota, a solicitação será negada com 401.

    curl  http://xxx.test.com/test?apikey=2bda943c-ba2b-11ec-ba07-00163e1250b5
  • Se a política estiver ativada, mas o consumidor não estiver autorizado, a solicitação será negada com 403.

    curl  http://xxx.test.com/test?apikey=2bda943c-ba2b-11ec-ba07-00163e1250b5

Códigos de erro relacionados

Código de status HTTP

Mensagem de erro

Descrição

401

Request denied by Key Auth check. Multi API key found in request.

Várias chaves de API foram fornecidas na solicitação.

401

Request denied by Key Auth check. No API key found in request.

Nenhuma chave de API foi fornecida na solicitação.

401

Request denied by Key Auth check. Invalid API key.

A chave de API fornecida não tem permissão de acesso.

403

Request denied by Key Auth check. Unauthorized consumer.

O chamador da solicitação não está autorizado.

Referências

Autorize e gerencie suas APIs por meio do Gerenciamento de autorização.