Tous les produits
Search
Centre de documentation

API Gateway:Authentification et autorisation des consommateurs

Dernière mise à jour :Aug 09, 2026

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

Instance > Security Management > Global Authentication.

  1. API Management > Détails de l'API HTTP > Gestion des routes > Configuration de la politique > Authentification du consommateur.

  2. API Management > Détails de l'API WebSocket > Gestion des routes > Configuration de la politique > Authentification du consommateur.

  3. API Management > Détails de l'API REST > Attacher une politique > Authentification du consommateur.

  4. Consumers > Détails du consommateur > Autorisation du consommateur.

Configuration de la méthode d'authentification (exemple d'authentification JWT)

  1. Lors de la création d'une configuration, fournissez la configuration globale JWKS.

  2. Saisissez les champs issue et sub pour vérifier le JWT.

  1. Lors de la création d'une configuration de consommateur, fournissez la configuration JWKS correspondante pour ce consommateur.

  2. Fournissez un identifiant de consommateur pour vérifier que le JWT appartient au bon consommateur. Par défaut, il s'agit du champ uid dans le payload, mais vous pouvez le personnaliser.

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.

  • Blacklist Mode : Les requêtes vers un Domain Name et un Path figurant sur la liste nécessitent une authentification. Toutes les autres requêtes n'en nécessitent pas.

  • Whitelist Mode : Les requêtes vers un domaine et un Path figurant sur la liste ne nécessitent pas d'authentification. Toutes les autres requêtes doivent être authentifiées.

  1. Dans les paramètres Configure Policy d'une route ou d'une API, activez l'Authentication.

  2. Dans Autorisation du consommateur, accordez au consommateur l'accès à la route ou à l'API authentifiée pour finaliser le processus d'autorisation.

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

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

  2. La passerelle transfère la requête au service backend.

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

  4. La passerelle renvoie le jeton au client. Le client met ce jeton en cache localement.

  5. Le client envoie une requête métier avec le jeton mis en cache à la passerelle.

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

  7. Le backend traite la requête et renvoie une réponse.

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

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

      Remarque

      Les 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 PAYLOAD du 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 :

  1. Vérifiez si la requête inclut un jeton. Sinon, rejetez-la avec le code 401.

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

  3. 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 iss.

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 :

  1. Extrayez la chaîne à signer : extrayez les données clés de la requête d'origine pour former une chaîne à signer.

  2. Créez la signature : chiffrez la chaîne à signer avec la SK pour produire la signature finale.

  3. 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 valeur Content-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_offset n'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-Type et Date.

  • 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 + "=" + ValueN
    Important
    • Triez 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 sont HmacSHA256 ou HmacSHA1. Ce champ est facultatif et sa valeur par défaut est HmacSHA256.

  • 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 :

  1. Extraire la chaîne à signer : extrayez les données clés de la requête reçue pour former une chaîne à signer.

  2. Récupérer la SK : lisez l'AK de la requête et utilisez-la pour récupérer la SK correspondante.

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

  4. 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 x-ca-key est manquant ou la clé est invalide.

401

Empty Signature

L'en-tête x-ca-signature est manquant.

400

Invalid Signature

La signature dans l'en-tête x-ca-signature ne correspond pas à la signature calculée par le serveur.

400

Invalid Content-MD5

L'en-tête Content-MD5 est incorrect.

400

Invalid Date

Le décalage temporel calculé à partir de l'en-tête Date dépasse le date_offset configuré.

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 DownstreamConnectionBufferLimits configuré globalement.

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 :

  1. Source d'informations d'identification par défaut : Authorization: Bearer <token>.

  2. En-tête personnalisé : fournissez un nom d'en-tête.

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