Software-Lizenzierung

Die meisten Softwareprodukte brauchen eine Möglichkeit zu kontrollieren, wer sie nutzen darf und unter welchen Bedingungen. Ob du eine Desktop-Anwendung, einen On-Premise-Server, ein CLI-Tool oder ein SDK auslieferst — du musst Fragen beantworten wie: “Hat dieser Benutzer bezahlt?”, “Wie viele Arbeitsplätze sind erlaubt?”, “Ist diese Lizenz noch gültig?” und “Darf dieses Gerät die Software ausführen?”

Auris Licensing bietet ein vollständiges System zum Ausstellen, Validieren und Verwalten von Software-Lizenzschlüsseln. Es ist in die Auris-Plattform integriert — zusammen mit Authentifizierung und Autorisierung — sodass du die Lizenzierung direkt mit deinen bestehenden Benutzern, Organisationen und Tenants verknüpfen kannst.

Das Lizenzmodell

Auris Licensing ist um drei Kernkonzepte herum aufgebaut: Richtlinien (Policies), Schlüssel (Keys) und Berechtigungen (Entitlements). Sie bilden eine Hierarchie, die die Vorlage (welche Art von Lizenz) von der Instanz (eine bestimmte Lizenz, die an einen bestimmten Kunden vergeben wird) und von den Gewährungen (was die Lizenz tatsächlich erlaubt) trennt.

Richtlinien (Policies)

Eine Richtlinie ist eine Vorlage, die die Regeln und die Struktur einer Lizenzklasse definiert. Richtlinien werden erstellt, bevor Schlüssel ausgestellt werden. Ein einzelnes Produkt kann mehrere Richtlinien haben — eine für die Testversion, eine für den persönlichen Plan, eine für den Enterprise-Plan.

Eine Richtlinie definiert:

Richtlinien sind bewusst unveränderlich. Wenn du die Bedingungen für neue Kunden ändern musst, erstellst du eine neue Richtlinienversion. Bestehende Schlüssel, die unter der alten Richtlinie ausgestellt wurden, behalten ihre ursprünglichen Bedingungen, sofern sie nicht explizit migriert werden.

Schlüssel (Keys)

Ein Schlüssel ist eine spezifische Lizenzinstanz, die auf Basis einer Richtlinie ausgestellt und einem Lizenznehmer zugewiesen wird. Der Lizenznehmer kann ein Benutzer, eine Organisation oder ein Gerät sein — je nach deinem Lizenzmodell.

Wenn ein Schlüssel erstellt wird, führt Auris Folgendes aus:

1. Generiert die Schlüsselzeichenkette gemäß dem Schlüsselformat der Richtlinie
2. Erfasst die Zuordnung zwischen Schlüssel, Richtlinie und Lizenznehmer
3. Berechnet die anfänglichen Berechtigungen basierend auf den Standardwerten der Richtlinie
4. Setzt das Ablaufdatum (falls die Richtlinie eine Dauer hat)
5. Löst ein license.key.created-Event aus (für Webhooks und Automatisierung)

Schlüssel haben einen Lebenszyklus:

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

• Active: Der Schlüssel besteht die Validierungsprüfungen und der Lizenznehmer kann die Software nutzen.
• Suspended: Vorübergehend deaktiviert (z.B. Zahlung fehlgeschlagen). Kann reaktiviert werden.
• Expired: Die Gültigkeitsdauer des Schlüssels ist abgelaufen. Kann nicht ohne Ausstellung eines neuen Schlüssels oder Verlängerung des Ablaufdatums reaktiviert werden.
• Revoked: Dauerhaft durch einen Administrator ungültig gemacht. Kann nicht reaktiviert werden.

Berechtigungen (Entitlements)

Berechtigungen sind das, was der Schlüssel zur Laufzeit tatsächlich gewährt. Es sind die konkreten Erlaubnisse und Limits, gegen die deine Anwendung prüft.

Berechtigungen umfassen:

• Feature-Flags: Benannte boolesche Werte (z.B. advanced-analytics, custom-branding, api-access)
• Arbeitsplatzanzahl: Wie viele Benutzer die Software gleichzeitig oder insgesamt nutzen können
• Geräteanzahl: Auf wie vielen Maschinen der Schlüssel aktiviert werden kann
• Ablaufdatum: Wann die Berechtigungen verfallen
• Metadaten: Beliebige Schlüssel-Wert-Paare für benutzerdefinierte Lizenzlogik

Obwohl Berechtigungen zunächst aus der Richtlinie abgeleitet werden, können sie pro Schlüssel überschrieben werden. Dies ermöglicht es, Ausnahmen zu behandeln, ohne eine neue Richtlinie zu erstellen — zum Beispiel einem bestimmten Kunden 5 zusätzliche Arbeitsplätze als Teil einer ausgehandelten Vereinbarung zu gewähren.

Validierungsmodi

Wenn deine Anwendung prüfen muss, ob eine Lizenz gültig ist, führt sie eine Validierungsprüfung durch. Auris unterstützt drei Validierungsmodi mit jeweils unterschiedlichen Kompromissen zwischen Sicherheit, Verfügbarkeit und Latenz.

Online-Validierung

Jede Validierungsprüfung führt einen API-Aufruf an Auris durch:

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

Die API überprüft, ob der Schlüssel existiert, aktiv ist, nicht abgelaufen ist und ob sich das aktuelle Gerät bzw. der aktuelle Benutzer innerhalb der erlaubten Grenzen befindet. Die Antwort enthält das vollständige Berechtigungsobjekt.

Stärken: Immer aktuell. Widerrufe werden sofort wirksam. Arbeitsplatz- und Gerätezählungen sind in Echtzeit genau.

Schwächen: Erfordert Netzwerkverbindung. Fügt jeder Prüfung Latenz hinzu. Wenn Auris nicht erreichbar ist, kann die Anwendung nicht validieren.

Ideal für: SaaS-Anwendungen, Web-Apps und jede Umgebung mit zuverlässiger Internetverbindung.

Hybrid-Validierung

Online-zuerst mit signiertem JWT-Fallback für Offline-Szenarien:

Client → POST /api/licensing/validate → Erfolg? Antwort verwenden
                                       → Fehler/Timeout? Gecachtes JWT verwenden

Wenn eine Online-Validierung erfolgreich ist, gibt die API neben den Berechtigungen ein signiertes Lizenz-Token (JWT) zurück. Der Client speichert dieses JWT lokal im Cache. Wenn ein nachfolgender Validierungsversuch fehlschlägt (Netzwerkfehler, Timeout), greift der Client auf das gecachte JWT zurück.

Das Lizenz-JWT enthält:

{
  "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"
  }
}

Das JWT wird mit dem privaten Schlüssel des Tenants signiert (RS256). Deine Anwendung überprüft die Signatur mit dem öffentlichen Schlüssel vom JWKS-Endpoint — kein Netzwerkaufruf an Auris für die Cache-Validierung nötig.

Stärken: Funktioniert offline für die Dauer des exp-Claims im JWT. Online-Prüfungen halten die Berechtigungen aktuell. Graceful Degradation.

Schwächen: Während Offline-Perioden werden Widerrufe und Berechtigungsänderungen erst wirksam, wenn das JWT abläuft und eine neue Online-Prüfung erfolgreich ist.

Ideal für: Desktop-Anwendungen, mobile Apps und Umgebungen mit intermittierender Konnektivität.

Offline-Validierung

Reine JWT-Validierung ohne jegliche Netzwerkabhängigkeit:

Client → JWT-Signatur lokal verifizieren → exp-Claim prüfen → Berechtigungen lesen

Das Lizenz-JWT wird einmalig (bei der Aktivierung) ausgestellt und auf dem Client gespeichert. Jede Validierungsprüfung ist eine lokale kryptografische Operation — Signatur verifizieren, Ablauf prüfen, Berechtigungen lesen.

Stärken: Keine Netzwerkabhängigkeit. Validierung in unter einer Millisekunde. Funktioniert in Air-Gapped-Umgebungen.

Schwächen: Berechtigungsänderungen erfordern eine Neuausstellung und Neuimportierung des JWT. Widerrufe basieren auf dem separaten Widerrufslisten-Mechanismus (siehe Widerruf).

Ideal für: On-Premise-Software, eingebettete Systeme, Air-Gapped-Umgebungen und jedes Szenario, in dem der Client keine externe API kontaktieren kann oder sollte.

Floating-Lizenzen

Traditionelle arbeitsplatzbasierte Lizenzierung weist Arbeitsplätze dauerhaft zu — bei 10 Arbeitsplätzen können nur 10 namentlich benannte Benutzer die Software nutzen. Floating-Lizenzen verfolgen einen anderen Ansatz: Arbeitsplätze werden temporär ausgeliehen und zurückgegeben, wenn sie nicht mehr benötigt werden.

Dies ist ideal für Organisationen, in denen viele Mitarbeiter gelegentlichen Zugang benötigen, aber nur wenige die Software gleichzeitig nutzen. Ein Unternehmen mit 50 Mitarbeitern benötigt möglicherweise nur 10 Floating-Arbeitsplätze, wenn nicht mehr als 10 Personen die Software gleichzeitig verwenden.

Wie Floating-Lizenzen funktionieren

Der Lebenszyklus von Floating-Lizenzen umfasst drei Operationen:

Checkout

Wenn ein Benutzer die Anwendung startet, fordert der Client einen Arbeitsplatz-Lease von Auris an:

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

Auris prüft, ob ein Arbeitsplatz verfügbar ist (aktuelle aktive Leases < max. Arbeitsplätze). Ist ein Arbeitsplatz verfügbar, erstellt es einen Lease-Eintrag mit einer Ablaufzeit und gibt ein Lease-Token zurück. Sind alle Arbeitsplätze belegt, schlägt der Checkout mit einem SEATS_EXHAUSTED-Fehler fehl.

Heartbeat

Während der Benutzer die Software aktiv nutzt, verlängert der Client den Lease regelmäßig:

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

Der Heartbeat setzt den Ablauftimer des Leases zurück. Wenn der Client keine Heartbeats mehr sendet (Anwendungsabsturz, Netzwerkausfall, Benutzer abwesend), läuft der Lease automatisch ab.

Checkin

Wenn der Benutzer die Anwendung schließt, gibt der Client den Arbeitsplatz explizit frei:

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

Der Lease wird sofort gelöscht, wodurch der Arbeitsplatz für einen anderen Benutzer frei wird. Wenn der Client keinen Checkin durchführt (Absturz, erzwungenes Beenden), läuft der Lease automatisch nach Ablauf der Lease-Dauer ab.

Lease-Ablauf und Wiederherstellung

Der automatische Ablaufmechanismus ist entscheidend für Floating-Lizenzen. Ohne ihn würde ein abgestürzter Client dauerhaft einen Arbeitsplatz belegen. Auris führt eine regelmäßige Bereinigung durch, die abgelaufene Leases entfernt und sicherstellt, dass Arbeitsplätze immer wiederherstellbar sind.

Die Lease-Dauer ist ein Gleichgewicht zwischen Reaktionsfähigkeit und Resilienz:

• Kurze Leases (5-10 Minuten): Arbeitsplätze werden nach einem Absturz schnell wiederhergestellt, aber der Heartbeat-Traffic ist höher.
• Lange Leases (30-60 Minuten): Weniger Heartbeat-Traffic, aber ein abgestürzter Client belegt einen Arbeitsplatz länger.

Der empfohlene Standardwert liegt bei 15-30 Minuten, mit Heartbeats im halben Lease-Intervall.

Offline-Aktivierung

Einige Umgebungen haben überhaupt keinen Netzwerkzugang — Produktionsanlagen, klassifizierte Regierungsnetzwerke, medizinische Geräte, industrielle Steuerungssysteme. Für diese Szenarien unterstützt Auris einen vollständig offline ablaufenden Aktivierungsworkflow, bei dem der Client niemals direkt mit der Auris-API kommunizieren muss.

Der Offline-Aktivierungsablauf

Der Prozess beinhaltet einen menschlichen Vermittler, der Daten zwischen der Air-Gapped-Maschine und einer Maschine mit API-/Konsolenzugang transportiert:

Schritt 1: Der Client erzeugt eine Anfrage-Payload

Die Client-Anwendung erfasst den Lizenzschlüssel und einen Geräte-Fingerprint, verpackt sie in eine strukturierte Payload und kodiert sie als Base64-Zeichenkette:

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

Der Benutzer kopiert diese Base64-Zeichenkette (angezeigt als Text oder QR-Code) und bringt sie zu einer vernetzten Maschine.

Schritt 2: Der Administrator sendet die Anfrage

Der Administrator fügt die Anfrage-Payload in die Auris-Konsole ein (unter Licensing > Offline Activations) oder sendet sie über die API:

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

Auris validiert den Schlüssel, registriert den Geräte-Fingerprint und erzeugt ein signiertes Antwort-Token — ein JWT mit den vollständigen Berechtigungen, gebunden an den spezifischen Geräte-Fingerprint.

Schritt 3: Der Client importiert das Antwort-Token

Der Administrator kopiert das Antwort-Token zurück auf die Air-Gapped-Maschine. Die Client-Anwendung importiert es, überprüft die Signatur anhand eines mitgelieferten oder zuvor abgerufenen öffentlichen Schlüssels und aktiviert die Lizenz.

Ab diesem Punkt validiert der Client die Lizenz vollständig offline, indem er die JWT-Signatur überprüft und die Claims kontrolliert.

Geräte-Fingerprinting

Gerätegebundene Lizenzierung erfordert eine zuverlässige Methode zur Identifikation von Maschinen. Auris verwendet einen zusammengesetzten Fingerprint, der aus mehreren Hardware- und Betriebssystemattributen erstellt und in einen stabilen Bezeichner gehasht wird.

Der Fingerprint wird aus einer Kombination der folgenden Merkmale berechnet:

• CPU-Modell und Kernanzahl
• Gesamter Systemspeicher
• Betriebssystemtyp und -version
• Seriennummern der Festplatten
• MAC-Adressen der Netzwerkschnittstellen (gefiltert, um virtuelle Adapter auszuschließen)
• Maschinen-ID oder Hardware-UUID (plattformspezifisch)

Kein einzelnes Attribut wird isoliert verwendet, da sich jedes Attribut ändern kann (RAM-Upgrade, neue Netzwerkkarte). Stattdessen verwendet der Fingerprint einen schwellenwertbasierten Abgleichalgorithmus: Wenn eine ausreichende Anzahl von Attributen weiterhin übereinstimmt, wird der Fingerprint als dieselbe Maschine betrachtet. Dies toleriert kleinere Hardware-Änderungen und erkennt dennoch, wenn eine Lizenz auf eine grundlegend andere Maschine verschoben wurde.

Der Schwellenwert ist pro Richtlinie konfigurierbar:

Wenn eine Fingerprint-Abweichung über die konfigurierte Toleranz hinaus erkannt wird, schlägt die Validierung mit einem DEVICE_MISMATCH-Fehler fehl. Der Endbenutzer muss das alte Gerät deaktivieren (falls zugänglich) oder den Administrator kontaktieren, um die Gerätebindung zurückzusetzen.

Widerruf

Das Widerrufen eines Lizenzschlüssels bedeutet, dauerhaft oder vorübergehend zu verhindern, dass er die Validierung besteht. Wie schnell der Widerruf wirksam wird, hängt vom Validierungsmodus ab.

Online-Widerruf

Wenn ein Schlüssel widerrufen wird und der Client die Online-Validierung verwendet, ist der Widerruf sofort wirksam. Der nächste POST /api/licensing/validate-Aufruf gibt zurück:

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

Es ist kein zusätzlicher Mechanismus erforderlich — der Server ist die Quelle der Wahrheit.

Offline-Widerruf

Wenn der Client die Offline- oder Hybrid-Validierung verwendet, bleibt das JWT des widerrufenen Schlüssels bis zu seinem Ablauf kryptografisch gültig. Um dies zu adressieren, veröffentlicht Auris eine Widerrufsliste — ein signiertes JWT mit einem Array widerrufener Schlüssel-Identifikatoren und deren Widerrufszeitstempeln.

{
  "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" }
  ]
}

Clients, die Offline-Validierung unterstützen, sollten die Widerrufsliste regelmäßig vom Well-Known-Endpoint (GET /api/licensing/.well-known/revocation-list) abrufen und lokal zwischenspeichern. Während der Offline-Validierung prüft der Client das Lizenz-JWT und die zwischengespeicherte Widerrufsliste.

Kulanzfrist und TTL

Der Widerruf in Offline-Szenarien ist grundsätzlich verzögert. Zwei Konfigurationsoptionen steuern den Kompromiss:

Die Kulanzfrist existiert, um abrupte Unterbrechungen in Umgebungen zu vermeiden, in denen Konnektivität selten ist. Ein Air-Gapped-Client, der die Widerrufsliste wöchentlich abruft, wird Widerrufe innerhalb des Kulanzfensters trotzdem berücksichtigen. Nach der Kulanzfrist wird der Schlüssel unabhängig vom Cache-Zustand hart gesperrt.

Kundenportal

Auris Licensing enthält ein kundenorientiertes Portal, in dem Endbenutzer (Lizenznehmer) ihre eigenen Lizenzen einsehen und verwalten können, ohne den Softwareanbieter kontaktieren zu müssen.

Funktionsweise

Das Kundenportal wird über denselben von Auris gehosteten Login-Flow erreicht, der auch für die Authentifizierung verwendet wird. Wenn sich ein Benutzer anmeldet, sieht er nur die Lizenzen, die mit seinem Konto verknüpft sind — entweder direkt (benutzergebundene Schlüssel) oder über seine Organisationsmitgliedschaft (organisationsgebundene Schlüssel).

Das Portal bietet:

• Lizenzübersicht: Alle aktiven, abgelaufenen und suspendierten Schlüssel mit ihren Berechtigungen
• Geräteverwaltung: Aktivierte Geräte einsehen, ein Gerät deaktivieren um einen Slot freizugeben
• Offline-Token: Signierte Lizenz-JWTs für die Offline-Nutzung herunterladen
• Nutzungsverlauf: Arbeitsplatznutzung über die Zeit (für Floating-Lizenzen)
• Verlängerungsstatus: Ablaufdaten und Verlängerungslinks (wenn die Zahlungsintegration konfiguriert ist)

Trennung von der Admin-Verwaltung

Das Kundenportal ist von der Auris-Konsole getrennt. Administratoren in der Konsole haben volle Kontrolle über alle Lizenzen, Richtlinien und Schlüssel aller Kunden. Das Kundenportal zeigt nur das, was dem authentifizierten Benutzer gehört.

Diese Trennung bedeutet:

• Endbenutzer können die Lizenzen anderer Kunden nicht einsehen
• Endbenutzer können keine Richtlinieneinstellungen ändern oder neue Schlüssel erstellen
• Endbenutzer können Self-Service-Aktionen durchführen (Gerät deaktivieren, Offline-Token herunterladen) ohne Eingreifen des Administrators
• Administratoren können bestimmte Self-Service-Aktionen pro Richtlinie bei Bedarf deaktivieren

Automatisierung

Manuelle Lizenzverwaltung skaliert nicht. Wenn ein Kunde für deine Software bezahlt, soll der Lizenzschlüssel automatisch ausgestellt werden. Wenn ein Abonnement ausläuft, soll der Schlüssel suspendiert werden. Auris Licensing integriert sich mit Zahlungsanbietern und dem Auris-Event-System, um den gesamten Lebenszyklus zu automatisieren.

Zahlungs-Webhook-Integration

Auris unterstützt die direkte Integration mit Stripe und PayPal für zahlungsgesteuerte Lizenzierung:

Stripe:

• checkout.session.completed → Erstellt einen neuen Schlüssel gemäß der entsprechenden Richtlinie
• invoice.paid → Verlängert das Ablaufdatum des Schlüssels (Abonnementverlängerung)
• invoice.payment_failed → Suspendiert den Schlüssel (Kulanzfrist konfigurierbar)
• customer.subscription.deleted → Widerruft oder lässt den Schlüssel ablaufen

PayPal:

• PAYMENT.SALE.COMPLETED → Erstellt einen neuen Schlüssel
• BILLING.SUBSCRIPTION.RENEWED → Verlängert das Ablaufdatum
• BILLING.SUBSCRIPTION.CANCELLED → Widerruft oder lässt den Schlüssel ablaufen
• BILLING.SUBSCRIPTION.SUSPENDED → Suspendiert den Schlüssel

Event-Aktions-Zuordnung

Über Zahlungs-Webhooks hinaus ermöglicht das Auris-Event-System die Definition benutzerdefinierter Automatisierungsregeln. Jedes Lizenzereignis kann eine Aktion auslösen:

Diese Regeln werden in der Auris-Konsole unter Licensing > Automation Rules oder über die API konfiguriert. Sie integrieren sich mit derselben Actions Engine, die für Authentifizierungsflows verwendet wird, sodass du benutzerdefinierte JavaScript-Aktionen für komplexe Logik nutzen kannst.

Wie alles zusammenwirkt

Lizenzierung in Auris ist keine isolierte Funktion — sie ist in die umfassendere Plattform für Identitäts- und Zugriffsmanagement eingebettet:

• Benutzer und Organisationen aus Auris IAM sind die Lizenznehmer. Keine separate Benutzerdatenbank erforderlich.
• Authentifizierung über Auris Hosted Login steuert den Zugang zum Kundenportal.
• RBAC-Berechtigungen kontrollieren, wer Lizenzen in der Konsole verwalten darf (manage:licenses, view:licenses).
• FGA kann neben der Lizenzierung für feingranularen Ressourcenzugriff innerhalb einer lizenzierten Anwendung verwendet werden.
• Webhooks benachrichtigen deine Systeme in Echtzeit über Lizenzereignisse.
• Audit-Logs zeichnen jede Lizenzoperation auf (Schlüssel erstellt, validiert, widerrufen, Gerät aktiviert).

Diese Integration bedeutet, dass du Benutzer einmal definierst, einmal authentifizierst und sowohl Zugriffskontrolle als auch Lizenzierung über eine einzige Plattform verwaltest.

Verwandte Konzepte

• Sitzungen & Token-Rotation — Wie Sitzungen und JWTs in Auris funktionieren
• Tokens erklärt — JWT-Struktur, Signierung und Verifizierung
• Actions & Sandbox-Ausführung — Benutzerdefinierte Automatisierungslogik für Lizenzereignisse
• Multi-Tenancy — Wie Lizenzierung über Tenants hinweg funktioniert
• OAuth 2.0 & OIDC — Das Authentifizierungs-Framework hinter dem Kundenportal