Authentifier les échanges côté serveur
L’authentification identifie l’application et limite les opérations qu’elle peut effectuer. Les secrets restent sur votre serveur et ne sont jamais inclus dans une page publique ou un dépôt.
Clés et périmètre
Attribuez les accès à l’entreprise et au magasin concernés. Séparez les permissions techniques de configuration et les droits permettant de déplacer des fonds. La création d’une clé n’active pas automatiquement toutes les capacités financières.
En-têtes du modèle de référence
Le référentiel étudié utilise X-API-KEY et X-API-KEY-ID. Ces noms sont des éléments de compatibilité à vérifier avec le contrat exposé par l’API Kelyko ; ils ne sont pas une preuve du mécanisme implémenté.
GET /partner_api/stores HTTP/1.1
Host: api.kelyko.invalid
X-API-KEY: CLE_EXEMPLE_NON_OPERATIONNELLE
X-API-KEY-ID: IDENTIFIANT_EXEMPLE
Activation et erreurs
Une authentification invalide et une capacité non autorisée doivent produire des erreurs distinctes. Vérifiez le code HTTP et le code métier réellement retournés. Une erreur ne doit pas conduire à désactiver les contrôles ou à essayer une autre clé de marchand.
Rotation et restrictions
Prévoir création, révocation, rotation, stockage sécurisé et restriction par environnement. Les restrictions IP, si proposées, complètent les contrôles d’autorisation. Masquer les secrets dans les journaux et conserver une trace des actions sensibles.