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 |
. |
|
|
Configuração do método de autenticação (exemplo de autenticação JWT) |
|
|
|
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.
|
|
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
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.
O gateway encaminha a solicitação ao serviço de backend.
O backend valida as credenciais. Após a validação bem-sucedida, gera um token com uma chave privada e o retorna ao gateway.
O gateway retorna o token ao cliente, que o armazena em cache localmente.
O cliente envia uma solicitação de negócio com o token em cache para o gateway.
O gateway verifica o token usando a chave pública configurada. Se for válido, encaminha a solicitação ao backend.
O backend processa a solicitação e retorna uma resposta.
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.
-
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> -
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.NotaOs 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
PAYLOADdo 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:
Verifique se a solicitação inclui um token. Caso contrário, rejeite com 401.
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.
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 |
|
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:
Extraia a string a ser assinada: extraia dados essenciais da solicitação original para formar uma string para assinatura.
Crie a assinatura: criptografe a string a ser assinada com a SK para produzir a assinatura final.
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 deContent-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_offsetnã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-TypeeDate.
-
-
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 + "=" + ValueNImportanteOrdene 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ãoHmacSHA256ouHmacSHA1. 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:
Extraia a string a ser assinada: extraia dados essenciais da solicitação recebida para formar uma string para assinatura.
Recupere a SK: leia a AK da solicitação e use-a para recuperar a SK correspondente.
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.
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 |
|
401 |
Empty Signature |
O cabeçalho |
|
400 |
Invalid Signature |
A assinatura no cabeçalho |
|
400 |
Invalid Content-MD5 |
O cabeçalho |
|
400 |
Invalid Date |
O deslocamento de tempo calculado a partir do cabeçalho |
|
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 |
|
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:
Origem de credencial padrão:
Authorization: Bearer <token>.Cabeçalho personalizado: forneça um nome de cabeçalho.
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.