Licences

Scrydon est sous licence par organisation. La licence est fournie sous forme de bundle JSON contenant un JWT signé ainsi que la clé publique RSA correspondante. La plateforme vérifie le JWT à chaque requête à l'aide de la clé publique ; une fois le bundle installé, aucun appel réseau supplémentaire n'est requis pour la vérification.

{
  "jwt":       "eyJhbGciOiJSUzI1NiIs…",
  "publicKey": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkq…\n-----END PUBLIC KEY-----"
}

Le bundle est le seul format accepté. Les fichiers .jwt bruts sont rejetés par l'assistant de configuration — la clé publique doit accompagner le JWT pour que la vérification de signature fonctionne sans appel sortant.

Contenu d'une licence

Le payload du JWT encode :

Le JWT est signé avec une clé privée RSA détenue par Scrydon. La clé publique correspondante est livrée dans le bundle — il n'y a pas de clé publique pré-intégrée dans le chart, ce qui signifie que les rotations de clé sont sans interruption de service : un nouveau bundle apporte sa propre clé publique.

Application d'une licence — assistant /setup

Après une nouvelle installation, accédez à https://<votre-hôte>/platform/setup (ou /setup si vous avez monté l'interface platform à la racine). L'assistant guide à travers cinq étapes :

1. Licence — collez le bundle JSON dans la zone de texte, ou déposez le fichier .json dans la zone de téléchargement. L'assistant :
   • analyse le bundle et décode le JWT
   • vérifie la signature à l'aide de la clé publique fournie dans le bundle
   • contrôle exp par rapport à l'heure actuelle (rejette les licences déjà expirées)
   • affiche le niveau, l'organisation, les CPU / RAM / VRAM et les jours restants avant expiration
2. Compte administrateur — créez le premier administrateur. À la validation, le JWT de licence et la clé publique sont persistés dans la table platform_config (license_jwt, license_public_key), et l'utilisateur administrateur est créé.
3. Organisation — nommez votre tenant racine.
4. E-mail — configurez l'envoi d'e-mails (Resend, SMTP, ou ignorez et configurez ultérieurement).
5. Terminé — positionne platform_config.setup_completed = "true" et redirige vers la page d'accueil de la plateforme.

L'assistant est fail-closed : la route /setup n'est accessible que tant que setup_completed n'est pas défini. Une fois la licence installée et un administrateur créé, /setup redirige vers la connexion même en cas de pannes transitoires du serveur d'authentification.

Pré-initialisation de la licence (ignorer l'étape 1 de l'assistant)

Si vous préférez ne pas coller le bundle de manière interactive, le chart accepte le jwt et la publicKey du bundle comme secrets Helm. La plateforme les lit au premier démarrage et les écrit dans la table platform_config ; les redémarrages ultérieurs ignorent les variables d'environnement.

auth:
  secrets:
    LICENSE: |
      eyJhbGciOiJSUzI1NiIs...
    LICENSE_PUBLIC_KEY: |
      -----BEGIN PUBLIC KEY-----
      MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…
      -----END PUBLIC KEY-----

Lorsque les deux valeurs sont présentes, l'étape Licence de l'assistant s'ouvre déjà vérifiée — l'opérateur clique directement sur Continuer pour passer à l'étape Admin.

Fonctionnement de la validation à l'exécution

Le plugin Better-Auth @scrydon/better-auth-license s'exécute dans le pod api-platform. À chaque requête authentifiée touchant une capacité soumise à licence, il :

1. Lit le license_jwt et le license_public_key actuels depuis platform_config.
2. Vérifie la signature du JWT par rapport à la clé publique stockée.
3. Contrôle exp par rapport à l'heure actuelle.
4. Applique les feature flags basés sur le niveau encodés dans les claims (ex. analytics activé, agentic activé, nombre maximal d'utilisateurs).
5. En mode online uniquement, appelle périodiquement le serveur de licences Scrydon (license.scrydon.com/api/license/validate) pour vérifier les révocations. Si l'appel sortant échoue, la plateforme continue d'utiliser le résultat de vérification en cache jusqu'à l'expiration de la période de grâce.

Il n'y a pas de conteneur init license-check, pas de Secret Kubernetes nommé scrydon-license, et aucun montage de license.jwt sur disque — la licence réside dans la base de données aux côtés des autres configurations de la plateforme, ce qui signifie qu'elle survit aux redémarrages de pods, aux mises à jour d'images et aux ré-installations de chart tant que la base de données est intacte.

Modes de licence

Configuration via Helm :

license:
  enabled: true
  mode: online              # or offline / airgapped
  apiUrl: https://license.scrydon.com/api/license/validate
  gracePeriod: 2592000      # 30-day soft-fail window (seconds)

Période de grâce

license.gracePeriod (défaut 30 jours / 2 592 000 s) détermine combien de temps la plateforme tolère les échecs d'appel sortant au serveur de licences avant de verrouiller. Le compteur démarre au premier échec ; un appel réussi le réinitialise. Une fois la période de grâce écoulée sans appel réussi, la plateforme considère la licence comme invalide et désactive les fonctionnalités soumises à licence.

La période de grâce n'a aucun effet en mode offline / airgapped (pas d'appel sortant, rien à compenser).

Une licence expirée ou révoquée ne tue pas les pods en cours d'exécution. Les capacités soumises à licence renvoient 403 depuis l'API et l'interface affiche une bannière. Ne redémarrez les pods qu'après avoir appliqué une licence valide.

Inspection d'une licence

Depuis le navigateur (sans plateforme requise)

La documentation embarque un Vérificateur de licence côté navigateur. Déposez le bundle { jwt, publicKey } (ou collez un JWT brut) et il affiche le niveau, l'organisation, l'identifiant client, les droits et le délai avant expiration. Le décodage s'effectue entièrement côté client — rien ne quitte la page — ce qui fonctionne avant qu'un cluster n'existe, lors d'une procédure d'achat ou pour diagnostiquer un ticket de support.

Depuis l'interface

Paramètres Platform → Licence affiche le niveau, l'organisation, les droits, l'expiration et le mode. Les administrateurs d'organisation peuvent copier le JWT actuel pour les tickets de support et coller un bundle renouvelé.

Depuis l'API

curl -X POST https://<your-host>/api/auth/license/get-claims \
  -H "Content-Type: application/json" \
  -H "Cookie: <session-cookie>" \
  -d '{}'

Cet endpoint nécessite une session valide. En pratique, utilisez l'interface ou le SDK client auth (client.license.getClaims()).

Décodage du JWT en local

Le JWT est un JSON Web Token signé standard — vous pouvez décoder son payload (deuxième segment) sans aucun outillage Scrydon :

JWT=$(jq -r .jwt license-bundle.json)
SEG=$(echo "$JWT" | cut -d. -f2 | tr '-_' '+/')
PAD=$(( (4 - ${#SEG} % 4) % 4 ))
PAYLOAD=$(printf '%s%s' "$SEG" "$(printf '=%.0s' $(seq 1 $PAD))" | openssl base64 -d -A)
echo "$PAYLOAD" | jq .

{
  "sub": "cust_acme",
  "iss": "scrydon-license",
  "aud": "scrydon-platform",
  "exp": 1767225600,
  "jti": "lic_abc123",
  "scrydon": {
    "org": "Acme Corp",
    "tier": "enterprise",
    "entitlements": { "cpuCores": 16, "ramGb": 64, "vramGb": 0 }
  }
}

Convertissez exp en date :

date -r 1767225600     # macOS
date -d @1767225600    # Linux

Renouvellement et rotation

Votre équipe de compte Scrydon vous enverra un bundle actualisé avant l'expiration du bundle actuel. Pour l'appliquer sans interruption de service :

1. Ouvrez Paramètres Platform → Licence → Mettre à jour la licence.
2. Collez le nouveau bundle { jwt, publicKey }.
3. Validez. La plateforme valide le nouveau bundle, puis remplace atomiquement les lignes license_jwt et license_public_key.

Aucun redémarrage de pod n'est nécessaire — le plugin relit depuis la base de données à chaque requête. Les fonctionnalités soumises à licence restent disponibles en continu pendant l'échange.

Pourquoi les deux champs changent ensemble

La clé de signature de Scrydon peut changer indépendamment de l'expiration de la licence (ex. compromission de clé privée, rotation planifiée). Comme la clé publique voyage avec le JWT, une rotation de clé n'est qu'un autre échange de bundle — l'opérateur suit le même processus, et il n'y a pas de clé publique pré-intégrée dans le chart qui devrait être mise à jour séparément.

Dépannage

License has expired

Le exp du JWT est dépassé. Demandez un renouvellement à sales@scrydon.com et précisez votre identifiant client (le claim sub, visible sous Paramètres → Licence).

Invalid signature

Le JWT et la clé publique dans le bundle ne correspondent pas — généralement parce que le bundle a été édité ou copié-collé avec une troncature de ligne. Demandez un bundle vierge à votre équipe de compte et collez-le en entier.

License check failed (network) en mode online

La plateforme ne peut pas atteindre https://license.scrydon.com. Causes courantes :

• Pare-feu d'egress bloquant HTTPS sortant. Autorisez license.scrydon.com:443.
• Interception TLS par un proxy d'entreprise sans que le CA du proxy soit injecté dans le trust store des pods.
• La période de grâce a expiré et la plateforme a verrouillé les fonctionnalités soumises à licence — appliquez un bundle vierge ou rétablissez la connectivité pour lever le verrouillage.

Pour basculer vers la vérification locale uniquement, définissez license.mode: offline dans vos valeurs Helm et exécutez helm upgrade.

Setup is already complete lors de l'ouverture de /setup

La route /setup est intentionnellement à usage unique. Une fois platform_config.setup_completed = "true", la route redirige vers la connexion. Pour relancer l'assistant (ex. après avoir vidé la base de données), définissez setup_completed = "false" dans platform_config et rechargez.

Demander un renouvellement

Contactez sales@scrydon.com ou votre responsable de compte Scrydon avant l'expiration de votre licence actuelle. Fournissez votre identifiant client (le claim sub du JWT). Scrydon émettra un bundle { jwt, publicKey } actualisé.