Authentification

Remizo distingue trois publics, avec trois mécanismes.

Public	Mécanisme	Où
Caisses, Beone, sites marchands, intégrateurs	Clé d’API (X-Api-Key)	API moteur /v1 et WsOne /rest
Utilisateurs du studio et de la console	Jeton Keycloak (OIDC, PKCE)	API hub /v1
Hub → moteurs	Jeton de management (Bearer)	API moteur /mgmt (réseau interne)

Clés d’API

Format

rmz_<live|test>_<keyId 8 caractères>_<secret 32 caractères base62>

Exemple : rmz_live_7Hk2pQ9a_…. La clé complète n’est affichée qu’une seule fois, à sa création. Remizo n’en conserve que l’empreinte SHA-256.

Création

Dans le studio (rôles developer ou admin) ou la console : Paramètres → Clés d’API → Nouvelle clé, ou POST /workspaces/{ws}/api-keys :

{ "name": "Caisses Île-de-France", "env": "live",
  "scopes": ["transactions:write", "transactions:read", "customers:read", "coupons:read"],
  "storeCodes": ["S042", "S043"], "rateLimitPerSecond": 50, "expiresAt": null }

Portées

Portée	Autorise
transactions:write / transactions:read	simuler, évaluer, valider, annuler, rembourser / lire les transactions
points:write / points:read	réserver, confirmer, annuler un paiement en points / lire les soldes
coupons:write / coupons:read	consommer un coupon hors ticket / vérifier un coupon
customers:read	identifier un client, lire soldes, offres et coupons
events:write	envoyer des événements client
wsone	utiliser l’adaptateur WsOne

Vérification locale

Le moteur charge les empreintes en mémoire au démarrage et les recharge dès qu’une clé change (message du hub, avec une vérification périodique de secours). Aucun appel au hub ni à Keycloak n’a lieu sur le chemin de la caisse.

Réponses possibles : 401 unauthorized (clé absente, inconnue, expirée ou révoquée), 403 forbidden-scope, 403 forbidden-store (magasin non autorisé pour cette clé), 429 rate-limited (avec Retry-After).

Bonnes pratiques

• une clé par usage (réseau de caisses, site marchand, Beone), restreinte aux magasins concernés ;
• les clés test ne fonctionnent que sur la sandbox du workspace ;
• rotation : créez la nouvelle clé, déployez-la, puis révoquez l’ancienne ;
• jamais de clé dans le code d’un navigateur ou d’une application mobile.

Jetons Keycloak (studio, console)

Une seule URL de connexion, deux realms :

• studio : utilisateurs des enseignes. Chaque workspace est une Organization Keycloak (alias = slug du workspace) ; un utilisateur peut appartenir à plusieurs organisations. Le jeton contient le claim organization, par exemple {"acme": {}, "beone": {}}. Le SSO d’entreprise (Entra ID, Google, OIDC, SAML) se rattache à l’organisation.
• admin : équipe éditeur, MFA obligatoire, rôles platform_admin, platform_operator, platform_support.

Le hub vérifie sur chaque requête la signature, l’émetteur, l’expiration et l’audience remizo-hub, puis :

• pour /v1/workspaces/{ws}/… avec un jeton studio : le workspace doit figurer dans le claim organization et l’utilisateur doit être membre actif ; son rôle vient du hub (owner, admin, approver, marketer, developer, support, analyst, viewer), pas de Keycloak ;
• un jeton admin donne accès à tous les workspaces selon le rôle de plateforme ;
• sinon 403 workspace-not-in-token ou 403 forbidden.

Les applications utilisent le flux Authorization Code + PKCE (clients publics remizo-studio et remizo-console) et gardent les jetons en mémoire (jamais dans le stockage local du navigateur).

Appeler l’API hub depuis un script

Créez un client confidentiel dédié dans le realm (service account) et obtenez un jeton par client_credentials, avec l’audience remizo-hub. Demandez ce client à l’équipe éditeur : il n’est pas créé par défaut.

Jeton de management

Les routes /mgmt/* du moteur (rechargement, simulateur, validation CEL, statistiques, drainage) exigent Authorization: Bearer <REMIZO_ENGINE_MGMT_TOKEN>. Ce jeton est stocké dans OpenBao (mo/<slug>/engine) et le port de management n’est accessible que depuis le réseau du workspace (publié sur l’hôte en local uniquement, pour le débogage).