Licences logicielles

La plupart des logiciels ont besoin d’un moyen de contrôler qui peut les utiliser et selon quelles conditions. Que tu distribues une application de bureau, un serveur sur site, un outil en ligne de commande ou un SDK, tu dois répondre à des questions comme : « Cet utilisateur a-t-il payé ? », « Combien de postes sont autorisés ? », « Cette licence est-elle encore valide ? » et « Cet appareil peut-il exécuter le logiciel ? »

Auris Licensing fournit un système complet pour émettre, valider et gérer des clés de licence logicielle. Il est intégré à la plateforme Auris aux côtés de l’authentification et de l’autorisation, ce qui te permet de lier les licences directement à tes utilisateurs, organisations et tenants existants.

Le modèle de licence

Auris Licensing s’articule autour de trois concepts fondamentaux : les Politiques, les Clés et les Droits. Ils forment une hiérarchie qui sépare le modèle (quel type de licence) de l’instance (une licence spécifique attribuée à un client spécifique) des autorisations (ce que la licence accorde concrètement).

Politiques

Une politique est un modèle qui définit les règles et la forme d’une catégorie de licences. Tu crées des politiques avant d’émettre des clés. Un même produit peut avoir plusieurs politiques — une pour un essai, une pour un plan personnel, une pour un plan entreprise.

Une politique définit :

Les politiques sont immuables par conception. Lorsque tu dois modifier les conditions pour de nouveaux clients, tu crées une nouvelle version de la politique. Les clés existantes émises sous l’ancienne politique conservent leurs conditions d’origine, sauf migration explicite.

Clés

Une clé est une instance de licence spécifique émise à partir d’une politique et attribuée à un titulaire. Le titulaire peut être un utilisateur, une organisation ou un appareil — selon ton modèle de licence.

Lorsqu’une clé est créée, Auris :

1. Génère la chaîne de clé selon le format défini par la politique
2. Enregistre l’association entre la clé, la politique et le titulaire
3. Calcule les droits initiaux à partir des valeurs par défaut de la politique
4. Définit la date d’expiration (si la politique a une durée)
5. Émet un événement license.key.created (pour les webhooks et l’automatisation)

Les clés ont un cycle de vie :

Created → Active → [Suspended] → [Expired | Revoked]

• Active : La clé passe les contrôles de validation et le titulaire peut utiliser le logiciel.
• Suspended : Temporairement désactivée (par ex., échec de paiement). Peut être réactivée.
• Expired : La période de validité de la clé est écoulée. Ne peut être réactivée sans émettre une nouvelle clé ou prolonger l’expiration.
• Revoked : Définitivement invalidée par un administrateur. Ne peut être réactivée.

Droits

Les droits sont ce que la clé accorde concrètement à l’exécution. Ce sont les permissions et limites concrètes que ton application vérifie.

Les droits incluent :

• Indicateurs de fonctionnalités : Valeurs booléennes nommées (par ex., advanced-analytics, custom-branding, api-access)
• Nombre de postes : Combien d’utilisateurs peuvent utiliser le logiciel simultanément ou au total
• Nombre d’appareils : Sur combien de machines la clé peut être activée
• Date d’expiration : Quand les droits expirent
• Métadonnées : Paires clé-valeur arbitraires pour une logique de licence personnalisée

Bien que les droits soient initialement dérivés de la politique, ils peuvent être surchargés par clé. Cela te permet de gérer des exceptions sans créer de nouvelle politique — par exemple, accorder 5 postes supplémentaires à un client spécifique dans le cadre d’un accord négocié.

Modes de validation

Lorsque ton application doit vérifier la validité d’une licence, elle effectue un contrôle de validation. Auris prend en charge trois modes de validation, chacun avec des compromis différents entre sécurité, disponibilité et latence.

Validation en ligne

Chaque contrôle de validation effectue un appel API vers Auris :

Client → POST /api/licensing/validate → Auris API → Database → Response

L’API vérifie que la clé existe, est active, n’a pas expiré et que l’appareil/utilisateur actuel respecte les limites autorisées. La réponse inclut l’objet complet des droits.

Points forts : Toujours à jour. Les révocations prennent effet immédiatement. Le nombre de postes et d’appareils est précis en temps réel.

Points faibles : Nécessite une connectivité réseau. Ajoute de la latence à chaque vérification. Si Auris est injoignable, l’application ne peut pas valider.

Idéal pour : Les applications SaaS, les applications web et tout environnement disposant d’une connectivité Internet fiable.

Validation hybride

En ligne d’abord, avec un JWT signé en solution de repli pour les scénarios hors ligne :

Client → POST /api/licensing/validate → Success? Use response
                                       → Failure/timeout? Use cached JWT

Lorsqu’une validation en ligne réussit, l’API retourne un jeton de licence signé (JWT) accompagnant les droits. Le client met ce JWT en cache localement. Si une tentative de validation ultérieure échoue (erreur réseau, délai d’attente), le client utilise le JWT en cache.

Le JWT de licence contient :

{
  "sub": "key_abc123",
  "iss": "https://api.altovar.net",
  "iat": 1710000000,
  "exp": 1710086400,
  "entitlements": {
    "features": ["advanced-analytics", "api-access"],
    "maxSeats": 10,
    "maxDevices": 5
  },
  "policy": "pol_enterprise",
  "licensee": {
    "type": "organization",
    "id": "org_xyz"
  }
}

Le JWT est signé avec la clé privée du tenant (RS256). Ton application vérifie la signature à l’aide de la clé publique du point de terminaison JWKS — aucun appel réseau vers Auris n’est nécessaire pour la validation en cache.

Points forts : Fonctionne hors ligne pendant la durée du claim exp du JWT. Les vérifications en ligne maintiennent les droits à jour. Dégradation gracieuse.

Points faibles : Pendant les périodes hors ligne, les révocations et les modifications de droits ne sont pas reflétées tant que le JWT n’expire pas et qu’une nouvelle vérification en ligne ne réussit pas.

Idéal pour : Les applications de bureau, les applications mobiles et les environnements à connectivité intermittente.

Validation hors ligne

Validation uniquement par JWT, sans aucune dépendance réseau :

Client → Verify JWT signature locally → Check exp claim → Read entitlements

Le JWT de licence est émis une seule fois (lors de l’activation) et stocké sur le client. Chaque contrôle de validation est une opération cryptographique locale — vérification de la signature, contrôle de l’expiration, lecture des droits.

Points forts : Aucune dépendance réseau. Validation en moins d’une milliseconde. Fonctionne dans les environnements isolés.

Points faibles : Les modifications de droits nécessitent de réémettre et réimporter le JWT. Les révocations reposent sur le mécanisme séparé de liste de révocation (voir Révocation).

Idéal pour : Les logiciels sur site, les systèmes embarqués, les environnements isolés et tout scénario où le client ne peut pas ou ne doit pas contacter une API externe.

Licences flottantes

Les licences traditionnelles par poste attribuent les postes de manière permanente — si tu as 10 postes, seuls 10 utilisateurs nommés peuvent utiliser le logiciel. Les licences flottantes adoptent une approche différente : les postes sont loués temporairement et libérés lorsqu’ils ne sont plus utilisés.

C’est idéal pour les organisations où de nombreux employés ont besoin d’un accès occasionnel mais peu utilisent le logiciel simultanément. Une entreprise de 50 employés pourrait n’avoir besoin que de 10 postes flottants si pas plus de 10 personnes utilisent le logiciel en même temps.

Fonctionnement des licences flottantes

Le cycle de vie des licences flottantes comporte trois opérations :

Checkout

Lorsqu’un utilisateur lance l’application, le client demande un bail de poste à Auris :

POST /api/licensing/checkout
{
  "key": "key_abc123",
  "userId": "user_alice",
  "leaseDuration": 30  // minutes
}

Auris vérifie si un poste est disponible (baux actifs en cours < postes max.). Si un poste est disponible, il crée un enregistrement de bail avec un délai d’expiration et retourne un jeton de bail. Si tous les postes sont occupés, le checkout échoue avec une erreur SEATS_EXHAUSTED.

Heartbeat

Pendant que l’utilisateur utilise activement le logiciel, le client prolonge périodiquement le bail :

POST /api/licensing/heartbeat
{
  "leaseId": "lease_xyz",
  "extend": 30  // minutes
}

Le heartbeat réinitialise le minuteur d’expiration du bail. Si le client cesse d’envoyer des heartbeats (plantage de l’application, perte de réseau, absence de l’utilisateur), le bail expirera naturellement.

Checkin

Lorsque l’utilisateur ferme l’application, le client libère explicitement le poste :

POST /api/licensing/checkin
{
  "leaseId": "lease_xyz"
}

Le bail est supprimé immédiatement, libérant le poste pour un autre utilisateur. Si le client n’effectue pas le checkin (plantage, fermeture forcée), le bail expire automatiquement après l’écoulement de la durée du bail.

Expiration des baux et récupération

Le mécanisme d’expiration automatique est essentiel pour les licences flottantes. Sans lui, un client ayant planté occuperait un poste de manière permanente. Auris exécute un nettoyage périodique qui supprime les baux expirés, garantissant que les postes sont toujours récupérables.

La durée du bail est un équilibre entre réactivité et résilience :

• Baux courts (5-10 minutes) : Les postes sont récupérés rapidement après un plantage, mais le trafic de heartbeat est plus élevé.
• Baux longs (30-60 minutes) : Moins de trafic de heartbeat, mais un client ayant planté occupe un poste plus longtemps.

La durée recommandée par défaut est de 15 à 30 minutes, avec des heartbeats envoyés à la moitié de l’intervalle du bail.

Activation hors ligne

Certains environnements n’ont aucun accès réseau — systèmes de chaînes de production, réseaux gouvernementaux classifiés, dispositifs médicaux, systèmes de contrôle industriel. Pour ces scénarios, Auris prend en charge un processus d’activation entièrement hors ligne qui ne nécessite jamais que le client communique directement avec l’API Auris.

Le processus d’activation hors ligne

Le processus implique un intermédiaire humain qui transporte les données entre la machine isolée et une machine ayant accès à l’API ou à la console :

Étape 1 : Le client génère une charge utile de requête

L’application cliente collecte la clé de licence et une empreinte d’appareil, les regroupe dans une charge utile structurée et l’encode en chaîne base64 :

{
  "key": "key_abc123",
  "fingerprint": "fp_sha256_a1b2c3d4e5f6...",
  "requestedAt": "2025-06-15T10:30:00Z",
  "clientVersion": "2.4.1"
}

L’utilisateur copie cette chaîne base64 (affichée sous forme de texte ou de code QR) et l’apporte à une machine connectée.

Étape 2 : L’administrateur soumet la requête

L’administrateur colle la charge utile de la requête dans la console Auris (sous Licensing > Offline Activations) ou la soumet via l’API :

POST /api/licensing/activate/offline
{
  "requestPayload": "eyJrZXkiOiAia2V5X2FiYz..."
}

Auris valide la clé, enregistre l’empreinte de l’appareil et génère un jeton de réponse signé — un JWT contenant l’ensemble des droits, lié à l’empreinte spécifique de l’appareil.

Étape 3 : Le client importe le jeton de réponse

L’administrateur recopie le jeton de réponse sur la machine isolée. L’application cliente l’importe, vérifie la signature à l’aide d’une clé publique intégrée ou précédemment récupérée, et active la licence.

À partir de ce moment, le client valide la licence entièrement hors ligne en vérifiant la signature du JWT et en contrôlant ses claims.

Empreinte d’appareil

Les licences liées aux appareils nécessitent un moyen d’identifier les machines de manière fiable. Auris utilise une empreinte composite construite à partir de multiples attributs matériels et logiciels, condensée en un identifiant stable.

L’empreinte est calculée à partir d’une combinaison de :

• Modèle et nombre de cœurs du processeur
• Mémoire système totale
• Type et version du système d’exploitation
• Numéros de série des disques
• Adresses MAC des interfaces réseau (filtrage des adaptateurs virtuels)
• Identifiant machine ou UUID matériel (spécifique à la plateforme)

Aucun attribut n’est utilisé isolément, car n’importe lequel peut changer (une mise à niveau de la RAM, une nouvelle carte réseau). Au lieu de cela, l’empreinte utilise un algorithme de correspondance par seuil : si un nombre suffisant d’attributs correspondent encore, l’empreinte est considérée comme provenant de la même machine. Cela tolère des changements matériels mineurs tout en détectant quand une licence a été déplacée vers une machine fondamentalement différente.

Le seuil est configurable par politique :

Lorsqu’une discordance d’empreinte est détectée au-delà de la tolérance configurée, la validation échoue avec une erreur DEVICE_MISMATCH. L’utilisateur final doit désactiver l’ancien appareil (s’il est accessible) ou contacter l’administrateur pour réinitialiser la liaison d’appareil.

Révocation

Révoquer une clé de licence signifie empêcher de manière permanente ou temporaire qu’elle passe la validation. La rapidité avec laquelle la révocation prend effet dépend du mode de validation.

Révocation en ligne

Lorsqu’une clé est révoquée et que le client utilise la validation en ligne, la révocation est immédiate. Le prochain appel POST /api/licensing/validate retourne :

{
  "ok": true,
  "data": {
    "valid": false,
    "code": "KEY_REVOKED",
    "message": "This license key has been revoked."
  }
}

Aucun mécanisme supplémentaire n’est nécessaire — le serveur est la source de vérité.

Révocation hors ligne

Lorsque le client utilise la validation hors ligne ou hybride, le JWT de la clé révoquée reste cryptographiquement valide jusqu’à son expiration. Pour résoudre ce problème, Auris publie une liste de révocation — un JWT signé contenant un tableau d’identifiants de clés révoquées et leurs horodatages de révocation.

{
  "iss": "https://api.altovar.net",
  "iat": 1710000000,
  "exp": 1710086400,
  "revoked": [
    { "key": "key_abc123", "revokedAt": "2025-06-15T14:00:00Z" },
    { "key": "key_def456", "revokedAt": "2025-06-14T09:30:00Z" }
  ]
}

Les clients prenant en charge la validation hors ligne doivent périodiquement récupérer la liste de révocation depuis le point de terminaison connu (GET /api/licensing/.well-known/revocation-list) et la mettre en cache localement. Pendant la validation hors ligne, le client vérifie le JWT de licence et la liste de révocation en cache.

Période de grâce et TTL

La révocation dans les scénarios hors ligne est intrinsèquement retardée. Deux options de configuration contrôlent le compromis :

La période de grâce existe pour éviter une interruption brutale dans les environnements où la connectivité est rare. Un client isolé qui récupère la liste de révocation chaque semaine honorera tout de même les révocations dans la fenêtre de grâce. Après la période de grâce, la clé est bloquée définitivement quel que soit l’état du cache.

Portail client

Auris Licensing inclut un portail orienté client où les utilisateurs finaux (titulaires de licence) peuvent consulter et gérer leurs propres licences sans contacter l’éditeur du logiciel.

Fonctionnement

Le portail client est accessible via le même flux de connexion hébergé par Auris utilisé pour l’authentification. Lorsqu’un utilisateur se connecte, il ne voit que les licences associées à son compte — directement (clés liées à l’utilisateur) ou via son appartenance organisationnelle (clés liées à l’organisation).

Le portail fournit :

• Vue d’ensemble des licences : Toutes les clés actives, expirées et suspendues avec leurs droits
• Gestion des appareils : Voir les appareils activés, désactiver un appareil pour libérer un emplacement
• Jetons hors ligne : Télécharger les JWT de licence signés pour une utilisation hors ligne
• Historique d’utilisation : Utilisation des postes au fil du temps (pour les licences flottantes)
• Statut de renouvellement : Dates d’expiration et liens de renouvellement (si l’intégration de paiement est configurée)

Séparation de la gestion administrative

Le portail client est distinct de la console Auris. Les administrateurs dans la console ont un contrôle total sur l’ensemble des licences, politiques et clés de tous les clients. Le portail client affiche uniquement ce qui appartient à l’utilisateur authentifié.

Cette séparation signifie :

• Les utilisateurs finaux ne peuvent pas voir les licences d’autres clients
• Les utilisateurs finaux ne peuvent pas modifier les paramètres des politiques ni créer de nouvelles clés
• Les utilisateurs finaux peuvent effectuer des actions en libre-service (désactiver un appareil, télécharger un jeton hors ligne) sans intervention de l’administrateur
• Les administrateurs peuvent désactiver des actions en libre-service spécifiques par politique si nécessaire

Automatisation

La gestion manuelle des licences ne passe pas à l’échelle. Quand un client paie pour ton logiciel, tu veux que la clé de licence soit émise automatiquement. Quand un abonnement expire, tu veux que la clé soit suspendue. Auris Licensing s’intègre aux fournisseurs de paiement et au système d’événements d’Auris pour automatiser l’ensemble du cycle de vie.

Intégration des webhooks de paiement

Auris prend en charge l’intégration directe avec Stripe et PayPal pour les licences pilotées par le paiement :

Stripe :

• checkout.session.completed → Créer une nouvelle clé selon la politique appropriée
• invoice.paid → Prolonger l’expiration de la clé (renouvellement d’abonnement)
• invoice.payment_failed → Suspendre la clé (période de grâce configurable)
• customer.subscription.deleted → Révoquer ou expirer la clé

PayPal :

• PAYMENT.SALE.COMPLETED → Créer une nouvelle clé
• BILLING.SUBSCRIPTION.RENEWED → Prolonger l’expiration
• BILLING.SUBSCRIPTION.CANCELLED → Révoquer ou expirer la clé
• BILLING.SUBSCRIPTION.SUSPENDED → Suspendre la clé

Mappage événement-action

Au-delà des webhooks de paiement, le système d’événements d’Auris te permet de définir des règles d’automatisation personnalisées. Tout événement de licence peut déclencher une action :

Ces règles se configurent dans la console Auris sous Licensing > Automation Rules ou via l’API. Elles s’intègrent au même Actions Engine utilisé pour les flux d’authentification, te permettant d’utiliser des actions JavaScript personnalisées pour une logique complexe.

Comment tout s’articule

Le système de licences dans Auris n’est pas une fonctionnalité isolée — il est intégré à la plateforme plus large de gestion des identités et des accès :

• Les utilisateurs et organisations d’Auris IAM sont les titulaires de licence. Aucune base de données utilisateur séparée n’est nécessaire.
• L’authentification via Auris Hosted Login contrôle l’accès au portail client.
• Les permissions RBAC contrôlent qui peut gérer les licences dans la console (manage:licenses, view:licenses).
• Le FGA peut être utilisé en complément des licences pour un contrôle d’accès granulaire aux ressources au sein d’une application sous licence.
• Les webhooks notifient tes systèmes des événements de licence en temps réel.
• Les journaux d’audit enregistrent chaque opération de licence (clé créée, validée, révoquée, appareil activé).

Cette intégration signifie que tu définis les utilisateurs une seule fois, les authentifies une seule fois, et gères à la fois le contrôle d’accès et les licences depuis une plateforme unique.

Concepts associés

• Sessions & Token Rotation — Comment fonctionnent les sessions et les JWT dans Auris
• Tokens Explained — Structure, signature et vérification des JWT
• Actions & Sandboxed Execution — Logique d’automatisation personnalisée pour les événements de licence
• Multi-Tenancy — Comment les licences fonctionnent entre tenants
• OAuth 2.0 & OIDC — Le cadre d’authentification qui alimente le portail client