Intégration

Activation dans un logiciel

Flux recommandé, sessions, heartbeat, identifiant d’appareil et limites.

Flux recommandé

Au premier lancement, demander la clé puis activate avec un device_id stable.
Vérifier la signature Keyline-Signature et le nonce renvoyé.
Conserver le jeton de session en mémoire (pas besoin de le persister).
Envoyer heartbeat aux deux tiers de expires_in.
Au lancement suivant, réactiver : l’appareil déjà enregistré ne consomme pas de nouvelle activation.
À la désinstallation ou sur action de l’utilisateur, deactivate libère le poste.

Vérification de la signature

Chaque réponse (succès et erreurs) porte :

Keyline-Signature: kid=<identifiant de clé>,ts=<secondes unix>,sig=<base64url>

sig est une signature ECDSA P-256 / SHA-256 au format IEEE P1363 (r ‖ s, 64 octets) du message "<ts>.<corps HTTP exact>". Refusez toute réponse non signée, signée par une clé inconnue, ou dont le nonce ne correspond pas à celui envoyé.

Identifiant d’appareil

Dérivez-le d’un identifiant système stable (MachineGuid sous Windows, /etc/machine-id sous Linux, IOPlatformUUID sous macOS) et hachez-le localement avec un sel propre à votre logiciel. Keyline n’en conserve qu’une empreinte HMAC propre à l’application.

Limites

Le device_id est fourni par le client et peut être falsifié ; il limite le partage, il ne prouve pas l’identité matérielle. Toute vérification locale peut être contournée par un binaire modifié : faites dépendre les fonctionnalités à forte valeur d’appels serveur.

Hors ligne

Keyline ne fournit pas de jeton hors ligne. Si votre logiciel doit fonctionner sans réseau, mémorisez localement la date de la dernière validation réussie et appliquez une période de grâce courte, choisie selon votre tolérance au risque.

Limites de débit

30 activations par minute et par IP, 240 validations/heartbeats, quota par application et par organisation. Après 10 clés invalides en 10 minutes, l’IP est temporairement bloquée (y compris pour une clé valide). Respectez Retry-After.