Cloud-native API Gateway prend en charge l'authentification globale, l'authentification au niveau des routes et l'autorisation des consommateurs. Cette rubrique explique comment configurer chaque méthode d'authentification et autoriser les consommateurs à accéder à des routes et des API spécifiques.
Contexte
L'authentification globale convient aux scénarios B2C, tels que la connexion unifiée. L'authentification des consommateurs pour les routes et les API s'adresse aux scénarios B2B, comme l'octroi d'un accès aux API à des partenaires.
|
Élément |
Authentification globale |
Authentification des routes et autorisation des consommateurs |
|
Cas d'utilisation |
Scénarios B2C, tels que l'authentification par connexion unifiée. |
Scénarios B2B, tels que l'octroi d'un accès aux API à des partenaires. |
|
Différence clé |
L'autorisation est activée simultanément avec l'authentification. |
Après avoir activé l'authentification, vous devez configurer l'autorisation séparément. |
|
Chemin de configuration |
. |
|
|
Configuration de la méthode d'authentification (exemple d'authentification JWT) |
|
|
|
Configuration de la méthode d'autorisation |
Lors de la création d'une configuration, fournissez une liste de Domain Name et de Path pour une liste noire ou une liste blanche.
|
|
Remarques sur l'utilisation
Après avoir activé l'authentification des consommateurs, la politique prend effet immédiatement. Si aucun consommateur ni aucune règle d'autorisation n'est configuré pour une route ou une API publiée, la passerelle refuse toutes les requêtes par défaut.
Utiliser l'authentification et l'autorisation des consommateurs
Authentification JWT
Flux de travail de l'authentification JWT
Le client envoie une requête d'authentification à la passerelle, généralement avec le nom d'utilisateur et le mot de passe de l'utilisateur final.
La passerelle transfère la requête au service backend.
Le backend valide les informations d'identification. Après une validation réussie, il génère un jeton avec une clé privée et renvoie le jeton à la passerelle.
La passerelle renvoie le jeton au client. Le client met ce jeton en cache localement.
Le client envoie une requête métier avec le jeton mis en cache à la passerelle.
La passerelle vérifie le jeton à l'aide de la clé publique configurée. Si le jeton est valide, la passerelle transfère la requête au backend.
Le backend traite la requête et renvoie une réponse.
La passerelle transfère la réponse au client.
Les sections suivantes décrivent comment générer un jeton, envoyer une requête à la passerelle et valider le jeton à l'aide de la clé publique configurée.
Générer un jeton
L'exemple Java suivant montre comment générer un jeton. Vous pouvez utiliser des outils similaires dans d'autres langages.
-
Créez un projet Maven et ajoutez la dépendance.
Ajoutez la dépendance suivante au projet :
<dependency> <groupId>org.bitbucket.b_c</groupId> <artifactId>jose4j</artifactId> <version>0.7.0</version> </dependency> -
Choisissez une méthode pour générer le jeton.
Vous pouvez générer un jeton à l'aide d'une clé symétrique ou asymétrique.
Clé symétrique
Exemple de code :
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); } }Paramètres du code :
privateKeyJson: Le JWKS utilisé lors de la création du consommateur. Enregistrez le JWKS lors de la création du consommateur ou récupérez-le depuis la page de configuration de base du consommateur.Définissez l'identifiant du consommateur. L'instruction est
claims.setClaim("uid", "11215ac069234abcb8944232b79ae711"). Cet identifiant est généré automatiquement lors de la création d'un consommateur, mais peut être modifié. Vous pouvez également le récupérer depuis la page de configuration de base du consommateur.-
Définissez l'algorithme de chiffrement. L'instruction est
jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.HMAC_SHA256). Cet algorithme doit correspondre à celui du JWKS.RemarqueLes algorithmes de chiffrement pris en charge incluent ES256, ES384, ES512, RS256, RS384, RS512, PS256, PS384, PS512, HS256, HS384, HS512 et EdDSA.
Pour le chiffrement symétrique, la valeur de « k » doit être décodée.
jws.setKey(new HmacKey(Base64.decode(JsonUtil.parseJson(privateKeyJson).get("k").toString())));
-
Définissez la durée d'expiration. Le jeton doit expirer dans un délai de sept jours. Après expiration, générez un nouveau jeton.
... NumericDate date = NumericDate.now(); date.addSeconds(120*60); claims.setExpirationTime(date); claims.setNotBeforeMinutesInThePast(1); ... Vous pouvez ajouter des paramètres personnalisés à la charge utile (PAYLOAD) du JWKS selon vos besoins.
Clé asymétrique
Exemple de code :
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); } }Paramètres du code :
-
Les paramètres pour
privateKeyJson, l'identifiant du consommateur et la durée d'expiration sont similaires à ceux du chiffrement symétrique.Définissez l'algorithme de chiffrement à l'aide de l'instruction
jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.RSA_USING_SHA256). Cet algorithme doit correspondre à celui du JWKS.Pour un algorithme de chiffrement asymétrique, vous devez utiliser sa clé privée pour le chiffrement.
... jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.RSA_USING_SHA256); PrivateKey privateKey = new RsaJsonWebKey(JsonUtil.parseJson(privateKeyJson)).getPrivateKey(); jws.setKey(privateKey); ... Vous pouvez ajouter des paramètres personnalisés au
PAYLOADdu JWT.
Envoyer des requêtes métier
Cloud-native API Gateway prend en charge le transfert du jeton dans un en-tête de requête. Vous pouvez personnaliser le nom de l'en-tête et le préfixe du jeton. La clé et le préfixe de la requête doivent correspondre à ceux configurés dans la méthode d'authentification du consommateur.
-
Les requêtes sans JWT renvoient une erreur 401.
curl http://xxx.hello.com/test -
Les requêtes avec un JWT invalide renvoient une erreur 401.
curl http://xxx.hello.com/test -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyMyJ9.eyJpc3MiOiJhYmNkIiwic3ViIjoidGVzdCIsImlhdCI6MTY2NTY2MDUyNywiZXhwIjoxODY1NjczODE5fQ.-vBSV0bKeDwQcuS6eeSZN9dLTUnSnZVk8eVCXdooCQ1' -
Si une requête inclut un JWT valide mais que le consommateur n'est pas autorisé pour l'API ou la route, une erreur 403 est renvoyée.
# 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'
Validation du jeton côté serveur
La validation du jeton comporte trois étapes :
Vérifiez si la requête inclut un jeton. Sinon, rejetez-la avec le code 401.
Vérifiez la validité et la date d'expiration du jeton à l'aide de la clé publique du JWKS du consommateur. Si le jeton est invalide ou expiré, rejetez-le avec le code 401.
Vérifiez si le consommateur est autorisé à accéder à l'API ou à la route demandée.
Codes d'erreur courants
|
Code d'état HTTP |
Message d'erreur |
Description |
|
401 |
Jwt missing |
Le JWT est absent de l'en-tête de la requête. |
|
401 |
Jwt expired |
Le JWT a expiré. |
|
401 |
Jwt verification fails |
La vérification de la charge utile JWT a échoué, par exemple en raison d'une non-concordance de |
|
403 |
Access Denied |
Aucune autorisation pour accéder à la route actuelle. |
Authentification AK/SK (HMAC)
Génération de signature côté client
Le client génère une signature en trois étapes :
Extrayez la chaîne à signer : extrayez les données clés de la requête d'origine pour former une chaîne à signer.
Créez la signature : chiffrez la chaîne à signer avec la SK pour produire la signature finale.
Ajoutez la signature : ajoutez tous les en-têtes liés à la signature à la requête HTTP d'origine pour former la requête finale.
Étape 1 : Extraire la chaîne à signer
Extrayez les données clés de la requête HTTP et assemblez-les en une chaîne à signer au format suivant :
HTTPMethod
Accept
Content-MD5
Content-Type
Date
Headers
PathAndParameters
Ces sept champs constituent la chaîne à signer, séparés par des caractères de nouvelle ligne (\n). Si le champ Headers est vide, aucune nouvelle ligne n'est nécessaire après celui-ci. Pour tout autre champ vide, incluez son caractère de nouvelle ligne. La signature est sensible à la casse. Chaque champ est extrait comme suit :
HTTPMethod : La méthode HTTP, en majuscules. Exemple :
POST.Accept : La valeur de l'en-tête Accept. Peut être vide. Nous vous recommandons de définir explicitement l'en-tête Accept. S'il est vide, certains clients HTTP définissent une valeur par défaut de
*/*, ce qui entraîne l'échec de la vérification de la signature.-
Content-MD5 : La valeur de l'en-tête
Content-MD5. Peut être vide. Calculez cette valeur uniquement pour les requêtes dont le corps n'est pas un formulaire. Le code Java suivant montre comment calculer la valeurContent-MD5:String content-MD5 = Base64.encodeBase64(MD5(bodyStream.getbytes("UTF-8"))); Content-Type : La valeur de l'en-tête
Content-Type. Peut être vide.Date : La valeur de l'en-tête Date. Si
date_offsetn'est pas activé, ce champ peut être vide. Sinon, il est utilisé pour la vérification du décalage temporel.-
Headers : Sélectionnez les en-têtes spécifiques à inclure dans la signature. Concaténez-les comme suit :
-
Triez les clés d'en-tête par ordre alphabétique et concaténez-les :
HeaderKey1 + ":" + HeaderValue1 + "\n"\+ HeaderKey2 + ":" + HeaderValue2 + "\n"\+ ... HeaderKeyN + ":" + HeaderValueN + "\n"
Si la valeur d'un en-tête est vide, utilisez
HeaderKey+":"+"\n"pour la signature, en conservant la clé et les deux-points.Listez les clés de tous les en-têtes signés dans l'en-tête
X-Ca-Signature-Headers, séparées par des virgules.Les en-têtes suivants ne sont pas inclus dans le calcul de la signature :
X-Ca-Signature,X-Ca-Signature-Headers,Accept,Content-MD5,Content-TypeetDate.
-
-
PathAndParameters : Inclut le chemin, les paramètres de requête et les paramètres de formulaire. Construit comme suit :
Path + "?" + Key1 + "=" + Value1 + "&" + Key2 + "=" + Value2 + ... "&" + KeyN + "=" + ValueNImportantTriez les clés des paramètres de requête et de formulaire par ordre alphabétique avant de les concaténer.
Si les paramètres de requête et de formulaire sont vides, utilisez directement le chemin sans
?.Si la valeur d'un paramètre est vide, incluez uniquement la clé. Le signe égal (
=) n'est pas inclus.Si la requête ou le formulaire contient des paramètres de tableau (même clé, valeurs différentes), utilisez la première valeur pour le calcul de la signature.
Étape 2 : Créer la signature
Chiffrez et encodez la chaîne à signer pour produire la signature finale. Dans l'exemple suivant, stringToSign est la chaîne extraite, secret est la SK de la configuration AK/SK et sign est la signature générée :
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);
Décodez stringToSign en un tableau d'octets UTF-8, chiffrez-le et encodez le résultat en Base64 pour produire la signature.
Étape 3 : Ajouter la signature à la requête
Incluez les quatre en-têtes suivants dans la requête HTTP pour la vérification de la signature :
x-ca-key: L'AK de la configuration d'authentification AK/SK.x-ca-signature-method: L'algorithme de signature. Les valeurs valides sontHmacSHA256ouHmacSHA1. Ce champ est facultatif et sa valeur par défaut estHmacSHA256.x-ca-signature-headers: Une liste séparée par des virgules de toutes les clés d'en-tête incluses dans la signature. Ce champ est facultatif.x-ca-signature: La signature. Ce champ est obligatoire.
Vérification de la signature côté serveur
La vérification de la signature côté serveur fonctionne comme suit :
Extraire la chaîne à signer : extrayez les données clés de la requête reçue pour former une chaîne à signer.
Récupérer la SK : lisez l'AK de la requête et utilisez-la pour récupérer la SK correspondante.
Calculer la signature : utilisez le même algorithme de chiffrement et la SK récupérée pour chiffrer la chaîne à signer, ce qui produit une signature côté serveur.
Vérifier la signature : lisez la signature côté client de la requête et comparez-la à la signature côté serveur pour vérifier la concordance.
Dépannage
En cas d'échec de la vérification de la signature, le serveur renvoie sa chaîne à signer (StringToSign) dans l'en-tête de réponse X-Ca-Error-Message. Comparez la StringToSign côté serveur avec celle que vous avez calculée localement. Si elles correspondent, vérifiez si vous avez utilisé la bonne SK. Comme les en-têtes HTTP ne peuvent pas contenir de caractères de nouvelle ligne, les nouvelles lignes dans la StringToSign sont remplacées par # :
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`
Codes d'erreur associés
|
Code d'état HTTP |
Message d'erreur |
Description |
|
401 |
Invalid Key |
L'en-tête |
|
401 |
Empty Signature |
L'en-tête |
|
400 |
Invalid Signature |
La signature dans l'en-tête |
|
400 |
Invalid Content-MD5 |
L'en-tête |
|
400 |
Invalid Date |
Le décalage temporel calculé à partir de l'en-tête |
|
413 |
Request Body Too Large |
La taille du corps de la requête dépasse la limite de 32 Mo. |
|
413 |
Payload Too Large |
Le corps de la requête dépasse le |
|
403 |
Unauthorized Consumer |
L'appelant de la requête n'est pas autorisé. |
Exemple de code (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")
}
Authentification par clé d'API
La passerelle authentifie les requêtes en fonction de la source d'informations d'identification configurée. Le processus est similaire pour les API et les routes. Les exemples suivants utilisent des routes.
Trois types de sources d'informations d'identification sont disponibles pour les clés d'API :
Source d'informations d'identification par défaut :
Authorization: Bearer <token>.En-tête personnalisé : fournissez un nom d'en-tête.
Paramètre de requête personnalisé : fournissez un nom de paramètre de requête.
Source d'informations d'identification par défaut
Supposons qu'une requête corresponde à la route abc. La clé d'API est fournie dans l'en-tête Authorization avec le préfixe Bearer (notez l'espace final).
curl http://xxx.test.com/test -H 'Authorization: Bearer 2bda943c-ba2b-11ec-ba07-00163e1250b5'
Définir la clé d'API dans l'en-tête de la requête
curl http://xxx.test.com/test -H 'x-api-key: 2bda943c-ba2b-11ec-ba07-00163e1250b5'
Source d'en-tête personnalisé
Supposons que la requête corresponde à la route abc et que la clé d'API se trouve dans un en-tête personnalisé.
-
Si la clé d'API se trouve au mauvais emplacement (par exemple, en tant que paramètre de requête au lieu de l'en-tête personnalisé configuré), la requête est refusée avec le code 401.
curl http://xxx.test.com/test?apikey=2bda943c-ba2b-11ec-ba07-00163e1250b5 -
Si la politique est activée mais que le consommateur n'est pas autorisé, la requête est refusée avec le code 403.
curl http://xxx.test.com/test -H 'x-api-key: 2bda943c-ba2b-11ec-ba07-00163e1250b5'
Paramètre de requête personnalisé
Supposons que la requête corresponde à la route abc et que la clé d'API se trouve dans un paramètre d'URL.
-
Si l'authentification du consommateur n'est pas activée pour la route, la requête est refusée avec le code 401.
curl http://xxx.test.com/test?apikey=2bda943c-ba2b-11ec-ba07-00163e1250b5 -
Si la politique est activée mais que le consommateur n'est pas autorisé, la requête est refusée avec le code 403.
curl http://xxx.test.com/test?apikey=2bda943c-ba2b-11ec-ba07-00163e1250b5
Codes d'erreur associés
|
Code d'état HTTP |
Message d'erreur |
Description |
|
401 |
Request denied by Key Auth check. Multi API key found in request. |
Plusieurs clés d'API ont été fournies dans la requête. |
|
401 |
Request denied by Key Auth check. No API key found in request. |
Aucune clé d'API n'a été fournie dans la requête. |
|
401 |
Request denied by Key Auth check. Invalid API key. |
La clé d'API fournie n'est pas autorisée à accéder. |
|
403 |
Request denied by Key Auth check. Unauthorized consumer. |
L'appelant de la requête n'est pas autorisé. |
Références
Vous pouvez autoriser et gérer vos API via Gestion des autorisations.