Une seule clé d'API ne devrait pas tout ouvrir

Toutes les plateformes de cartes vous remettent une clé d'API dès le premier jour. Presque aucune ne demande ce que cette clé doit être autorisée à faire. La réponse est généralement « tout » : chaque carte, chaque détenteur, chaque écriture, pour toujours, jusqu'à ce que quelqu'un pense à la révoquer.

C'est acceptable pour un développeur seul qui fait des essais un mardi. Ça ne l'est plus dès qu'un tiers intervient sur votre compte : un prestataire d'analyse qui n'a besoin que de lire, un site d'événement qui n'a besoin d'émettre des billets que pour une seule carte, le client d'une agence qui veut sa propre intégration sans voir les autres clients de l'agence. Chacun reçoit la même clé maîtresse, et votre niveau de sécurité devient la somme de tous leurs ordinateurs portables.

Les clés Pass Studio portent désormais une portée. Voici ce que cela change concrètement.

Clés en lecture seule

Une clé en lecture seule peut lister les cartes, parcourir page par page les détenteurs d'une carte, rechercher un détenteur, lire les soldes de fidélité et vérifier un traitement par lots. Elle ne peut ni émettre, ni mettre à jour, ni révoquer, ni attribuer de points, ni enregistrer une utilisation. Toute écriture renvoie une erreur 403 avec un code lisible par machine, avant que la requête ne touche quoi que ce soit.

Confiez cette clé au prestataire du tableau de bord, à la synchronisation de l'entrepôt de données, au consultant chargé des rapports. Si elle fuite, le pire qui puisse arriver est que quelqu'un lise des données qu'il ne devrait pas voir. Personne n'émet dix mille cartes sur vos crédits.

Clés limitées à certaines cartes

Une clé peut être limitée à une seule carte, ou à une liste de cartes choisies. Chaque point d'accès qui cible une carte vérifie cette restriction, y compris ceux qui passent par un identifiant d'instance ou un code-barres plutôt que par l'identifiant de la carte : il n'y a pas de porte dérobée.

C'est la clé du site d'événement. La billetterie du festival de printemps reçoit une clé qui peut émettre sur la carte du festival, et rien d'autre. Une fois le festival terminé, révoquez-la. Votre programme de fidélité, vos cartes d'adhérent et l'événement de la saison prochaine n'ont jamais été accessibles avec cette clé.

Pour les agences, c'est la clé du prestataire du client. Le consultant CRM d'un client reçoit une clé limitée aux cartes de ce client, dans l'espace de travail de ce client. Les autres clients de l'agence ne sont pas simplement masqués : ils sont hors du champ d'autorité de la clé.

Une rotation avec chevauchement

Les clés devraient faire l'objet d'une rotation régulière, et après tout changement dans l'équipe. L'obstacle a toujours été le trou entre les deux : l'ancienne clé cesse de fonctionner, la nouvelle n'est pas encore déployée partout, et quelque chose casse en production au pire moment.

Lancez la rotation d'une clé Pass Studio et vous obtenez une remplaçante avec le même libellé et la même portée, tandis que l'ancienne clé continue de fonctionner pendant 24 heures avant d'expirer d'elle-même. Déployez la nouvelle clé à votre rythme dans ce délai. Le panneau des paramètres affiche le compte à rebours, et chaque clé indique quand elle a été utilisée pour la dernière fois : une clé devenue silencieuse est facile à repérer et à retirer. La rotation est accessible à tous et imposée à personne.

Ce qui se fait ailleurs

Nous avons vérifié comment l'acteur historique traite le même problème, parce qu'une affirmation comme « véritable facteur de différenciation » doit pouvoir être vérifiée. La propre documentation de PassKit décrit son jeton d'API à longue durée de vie comme donnant « un accès complet et permanent à l'API de votre compte ». Ses identifiants clé-et-secret ne portent pas de portée non plus. Son mécanisme de rotation consiste à laisser les anciens identifiants SDK valides pendant 30 jours, pour tout le compte. Son portail web n'offre qu'un seul identifiant de connexion par compte ; aux agences dont le personnel a besoin d'accès, il conseille de partager le mot de passe ou d'ouvrir un compte distinct par client.

Rien de tout cela n'est inhabituel dans ce secteur. C'est simplement le modèle avec lequel la plupart des plateformes ont démarré, sans jamais le revoir. Nous pensons que c'est la clé qui doit porter la permission, et non la personne qui la détient.

Comment cela s'intègre au reste du compte

Les portées s'ajoutent à des frontières qui existaient déjà. Les clés appartiennent à un espace de travail et ne peuvent jamais voir un autre espace de travail. Les équipes ont des rôles. Chaque clé est stockée sous forme hachée, affichée une seule fois et révocable en un clic. Chaque appel authentifié par clé renvoie des en-têtes de limite de débit, et chaque point d'accès de liste se pagine de la même manière. La portée est une chose de plus que la clé sait d'elle-même, et une chose de moins dont vous devez confier la bonne gestion à un tiers.

Pour commencer

Ouvrez les Paramètres, créez une clé et choisissez sa portée : complète ou en lecture seule, toutes les cartes ou seulement certaines. Les clés existantes continuent de fonctionner exactement comme avant ; ce sont des clés à portée complète, et vous pouvez les remplacer par des clés plus restreintes à votre rythme grâce à la rotation.

La référence complète, avec les codes d'erreur que renvoie une clé à portée limitée, se trouve dans le guide de l'API. Si vous êtes une agence, la page sur les organisations explique comment s'articulent clés, espaces de travail et facturation. La comparaison détaillée avec PassKit se trouve sur la page comparative. Ces trois pages sont en anglais.

Sources : articles 5743688 (jetons d'API à longue durée de vie) et 5360004 (plusieurs utilisateurs du portail) de help.passkit.com, consultés en septembre 2026 ; citations traduites de l'anglais.