SSO-Steuer: Wenn selbst gehostete Software extra kostet

Die SSO-Steuer

Die SSO-Steuer bei selbst gehosteter Software beschreibt das Muster, bei dem die Anwendung kostenlos ist, Single Sign-on (SSO) jedoch die eine Funktion ist, die Sie kaufen müssen. Sie können die gesamte Anwendung auf Ihrem eigenen VPS ohne Lizenzschlüssel und ohne Begrenzung der Benutzerzahl betreiben. Öffnen Sie anschließend die Dokumentation zur Authentifizierung, finden Sie OpenID Connect (OIDC) oder SAML (Security Assertion Markup Language) unter einem kostenpflichtigen Tarif.

Das ist wichtiger als eine gewöhnliche Funktion hinter einer Bezahlschranke, weil SSO dafür sorgt, dass sich mehrere selbst gehostete Dienste wie ein einziges System verhalten. Ein Identity Provider (IdP) stellt für jede Person ein Konto, eine zentrale Kennwortrichtlinie, eine zentrale Stelle zum Aktivieren der Multi-Faktor-Authentifizierung (MFA) und eine zentrale Stelle zum Sperren eines Kontos bereit. Ohne einen IdP verwaltet jede Anwendung ihre eigene kleine Benutzerdatenbank, und Sie müssen jede einzelne von Hand pflegen.

Dieses Muster ist alt genug für eine öffentliche Übersicht. Die SSO Wall of Shame auf sso.tax listet Anbieter auf, die für Single Sign-on einen hohen Aufpreis verlangen. Die Einträge reichen bis ins Jahr 2018 zurück. Der Autor setzt dabei eine faire Grenze: „Wenn Ihr SSO-Support den Preis um 10 % erhöht, stehen Sie nicht auf dieser Liste.“ Der größte Teil dieser Liste besteht aus proprietärer Software. Dieselbe Preislogik findet inzwischen auch bei Open-Source-Projekten Anwendung, die Sie selbst hosten.

Warum Maintainer Single Sign-On hinter einer kostenpflichtigen Stufe anbieten

Dafür gibt es zwei Gründe, und beide sind nachvollziehbar. SSO verursacht hohe Supportkosten. Außerdem gehört es zu den wenigen Funktionen, für die ein großes Unternehmen bezahlt.

Die Supportkosten entstehen tatsächlich, weil eine Identitätsintegration nie abgeschlossen ist. Jeder IdP formatiert seine Claims etwas anders. Gruppenmapping, Sitzungsdauer, Redirect-URLs und Zeitabweichungen verursachen jeweils eigene Login-Fehler. Ein Login-Fehler sperrt jedoch alle Benutzer gleichzeitig aus. Deshalb sind solche Supportanfragen dringend. Danach folgen weitere Anforderungen: verschachtelte Gruppen, Rollenmapping, automatische Bereitstellung mit SCIM (system for cross-domain identity management) und Audit-Logs, die von einem Compliance-Team ausgewertet werden.

Die Umsatzseite ist eine Rechenfrage und keine Böswilligkeit. Ein Unternehmen, das die Anwendung nicht mit dem eigenen IdP verbinden kann, wird sie überhaupt nicht bereitstellen. SSO zieht daher eine klare Grenze zwischen Benutzern, die bezahlen, und Benutzern, die nicht bezahlen. Ein Open-Core-Projekt muss diese Grenze an einer Stelle ziehen. SSO eignet sich dafür besser als fast jede andere Funktion. Deshalb entscheiden sich so viele Projekte dafür.

Eine Korrektur zur üblichen Kritik: Prüfen Sie das Changelog, bevor Sie annehmen, dass eine Funktion entfernt wurde. Eine Entfernung erscheint in den Release Notes. Bei den Projekten, die ich für diesen Beitrag geprüft habe, waren die kostenpflichtigen SSO-Funktionen von Anfang an für die kostenpflichtige Stufe vorgesehen. Ich habe keinen Fall gefunden, in dem funktionierendes kostenloses SSO zurückgezogen wurde. Grafana ist dafür typisch. Auf der SAML-Seite steht in einer einzeiligen Notiz: "Available in Grafana Enterprise and Grafana Cloud". Generisches OAuth gegen den eigenen Issuer funktioniert dagegen in der Open-Source-Version.

Was die SSO-Steuer tatsächlich kostet

Das Geld ist nur die kleinere Hälfte. Bezahlte Tarife werden pro Benutzer abgerechnet. Dadurch wächst die Rechnung mit Ihrem Team, während Sie Hosting und Upgrades weiterhin selbst verwalten müssen.

Die höheren Kosten entstehen durch die manuelle Identitätsverwaltung. Sie fallen an vier Stellen an.

• Für jede Anwendung gibt es einen eigenen Passwortspeicher. Ein wiederverwendetes Passwort stellt daher für jede Anwendung, in der es verwendet wird, eine Sicherheitslücke dar.
• Das Offboarding erfolgt aus dem Gedächtnis. Sie müssen sich an jeden Dienst erinnern, auf den eine Person Zugriff hatte. Der vergessene Dienst ist dann der relevante.
• MFA wird für jede Anwendung einzeln konfiguriert, sofern die Anwendung dies überhaupt unterstützt.
• Gemeinsame Anmeldungen werden unter diesem Druck in kleinen Teams tatsächlich verwendet.

Der letzte Punkt verdient einen eigenen Satz. Wenn ein Team in einer Dokumentenverwaltung ein gemeinsames Administratorkonto verwendet, enthält der Audit-Trail für alle Aktionen denselben Namen. Sie können daher nicht feststellen, wer die Rechnung gelöscht hat. Auch die Berechtigungen pro Benutzer funktionieren nicht mehr, weil es nur einen Benutzer gibt. Das ist der eigentliche Schaden der SSO-Steuer: Sie drängt kleine Teams zu einem gemeinsamen Konto, das schlechter ist als jede der Alternativen.

Die Checkliste vor der Einführung einer Anwendung

Führen Sie diese Prüfung vor docker compose up durch, nicht erst, nachdem die Anwendung 400 Dokumente enthält.

1. Öffnen Sie die Authentifizierungsseite in der Dokumentation und lesen Sie den Hinweis zur jeweiligen Stufe am Anfang. Kostenpflichtige Funktionen sind mit einem Badge oder einem einzeiligen Verfügbarkeitshinweis gekennzeichnet.
2. Prüfen Sie, ob die Anwendung per OIDC oder SAML mit Ihrem eigenen Issuer kommuniziert und nicht nur mit einer festen Liste öffentlicher Anbieter.
3. Prüfen Sie die Zuordnung von Rollen und Gruppen. Das Anlegen des Benutzers ist nur die halbe Arbeit. Die Berechtigungsvergabe per Hand in zehn Anwendungen ist der problematische Teil.
4. Prüfen Sie, ob die Anwendung einen authentifizierten Benutzernamen in einem Header von einem vertrauenswürdigen Proxy akzeptiert und ob Sie festlegen können, welchem Proxy sie vertraut.
5. Lesen Sie die Lizenzhistorie in git und prüfen Sie, ob die Mitwirkenden eine CLA (contributor licence agreement) unterzeichnen.
6. Prüfen Sie das Offboarding. Klären Sie, was mit API- (application programming interface) Tokens und aktiven Sitzungen geschieht, wenn das IdP-Konto deaktiviert wird.

Bei Punkt 2 entstehen die meisten Enttäuschungen. Eine Schaltfläche "Mit Google anmelden" ist kein OIDC mit Ihrem Identity Provider. Sie ist eine feste Integration mit einem Anbieter. Eine echte Unterstützung fordert von Ihnen eine Issuer-URL an. Alle weiteren Informationen stammen aus der Discovery. Die Seite Ihres Providers können Sie mit einem Befehl prüfen.

curl -s https://id.example.com/.well-known/openid-configuration \
  | jq '.issuer, .authorization_endpoint, .token_endpoint'

Von einem funktionierenden Provider werden drei URLs zurückgegeben. Ein leeres Ergebnis oder ein 404 bedeutet normalerweise, dass der Discovery-Pfad falsch ist. Dieser Pfad ist vom Provider abhängig: Keycloak veröffentlicht ihn unter /realms/<realm>/.well-known/openid-configuration. Wenn die Anwendung überhaupt kein Feld für eine Issuer-URL enthält, kann sie nicht mit Ihrem IdP kommunizieren, unabhängig davon, was die Funktionsliste angibt.

Punkt 6 wird oft erst Wochen nach dem Ausscheiden einer Person relevant. Durch die Deaktivierung des Kontos im IdP werden neue Anmeldungen verhindert. Ein API-Token, das die Anwendung zuvor ausgestellt hat, wird dadurch nicht widerrufen. Die Anwendung validiert dieses Token selbst und fragt den IdP dabei nicht ab. Das Offboarding umfasst daher zwei Schritte: Deaktivieren Sie das Konto im IdP. Löschen Sie anschließend den Benutzer oder dessen Tokens in jeder Anwendung.

Was die Tier-Badges tatsächlich aussagen

Diese Angaben wurden im August 2026 mit der jeweiligen Dokumentation der Projekte abgeglichen. Beginnen wir mit den kostenpflichtigen Angeboten.

Grafana führt SAML als „Available in Grafana Enterprise and Grafana Cloud“ auf, zusammen mit der Teamsynchronisierung und der SCIM-Bereitstellung. Generisches OAuth, GitHub OAuth, LDAP (lightweight directory access protocol) und der Auth-Proxy sind im Open-Source-Build enthalten. Ein kleiner Self-Hoster kann sich daher weiterhin über den eigenen Identity Provider anmelden. Die kostenpflichtige Grenze liegt bei SAML und nicht beim Single Sign-on insgesamt. Diese Unterscheidung geht durch den Begriff „SSO tax“ häufig verloren.

Metabase formuliert es eindeutiger. In der Dokumentation steht: „SAML authentication is only available on Pro and Enterprise plans (both self-hosted and on Metabase Cloud).“ Die Open-Source-Edition unterstützt weiterhin die Anmeldung per Passwort und LDAP.

Passbolt kennzeichnet seine SSO-Dokumentation als Pro und Cloud. Die Community-Edition unterstützt SSO daher nicht. Zu den dokumentierten Providern gehören Keycloak und Entra ID.

Nun zur anderen Seite, denn dieses Muster ist keineswegs allgemein gültig.

• GitLab Self-Managed führt auf seiner SAML-Seite „Tier: Free, Premium, Ultimate“ auf. SAML gegen die eigene GitLab-Instanz kostet daher nichts.
• Paperless-ngx konfiguriert OIDC über django-allauth mit PAPERLESS_SOCIALACCOUNT_PROVIDERS, blendet das lokale Anmeldeformular mit PAPERLESS_DISABLE_REGULAR_LOGIN aus und ordnet Claims mit PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS Gruppen zu.
• Planka verwendet OIDC_ISSUER, OIDC_CLIENT_ID und OIDC_CLIENT_SECRET, setzt die Scopes standardmäßig auf openid profile email und stuft Administratoren anhand eines Rollen-Claims mit OIDC_ADMIN_ROLES ein.
• BookStack aktiviert die Funktion mit AUTH_METHOD=oidc und ordnet anschließend Provider-Gruppen mit OIDC_USER_TO_GROUPS=true und OIDC_GROUPS_CLAIM den eigenen Rollen zu.
• Vaultwarden veröffentlichte in 1.35.0 am 27 December 2025 die „support for SSO with OpenID Connect“. Die Funktion stammte aus einem Pull Request eines Contributors, der sie zuvor in einem Fork gepflegt hatte.
• listmonk unterstützt seit v4.0.0 neben seinen Benutzerrollen auch die OIDC-Anmeldung.

Berücksichtigen Sie diese Informationen bei der Auswahl und nicht erst nach der Festlegung auf eine Lösung. Ein Planka-Kanban-Board und die anderen selbst gehosteten Trello-Alternativen behandeln Identitäten nicht alle gleich. Das gilt auch für BookStack, Wiki.js und Outline. Kostenloses OIDC ist ein Merkmal, das Sie ebenso wie Speicherlimits oder mobile Clients bewerten können. Wenn Sie noch eine Auswahlliste erstellen, ist was Sie 2026 selbst hosten sollten ein sinnvoller Ausgangspunkt. Sowohl der Paperless-ngx-Dokumentenmanager als auch Vaultwarden bieten Ihnen bereits heute kostenloses OIDC.

Warum ein Reverse Proxy vor der Anwendung kein Single Sign-on ist

Die übliche Lösung ist Forward Auth. Der Reverse Proxy hält jede Anfrage zurück, fragt einen Authentifizierungsdienst, ob dieser Browser angemeldet ist, und leitet die Anfrage erst dann an die Anwendung weiter. authentik nennt dies einen Proxy Provider mit einem Forward-Auth-Modus für eine einzelne Anwendung und einem weiteren Modus für eine gesamte Domain. Authelia und oauth2-proxy erfüllen dieselbe Aufgabe.

Ein Caddy-Site-Block sieht entsprechend dem eigenen Beispiel von authentik so aus.

app.example.com {
  forward_auth http://authentik-outpost:9000 {
    uri /outpost.goauthentik.io/auth/caddy
    copy_headers X-Authentik-Username X-Authentik-Email X-Authentik-Groups
    trusted_proxies private_ranges
  }
  reverse_proxy app:8000
}

Bei diesen Header-Namen ist die Groß- und Kleinschreibung in Caddy relevant, weil ein nicht übereinstimmender Name leer ankommt. Bei jeder genehmigten Anfrage setzt der Outpost X-authentik-username, X-authentik-email, X-authentik-groups und einige weitere Header.

Das ist der konkrete Nutzen: Niemand erreicht die Anwendung, ohne zuerst den Identity Provider zu passieren. Dadurch ist ein ungepatchtes Anmeldeformular nicht mehr aus dem Internet erreichbar, und MFA gilt gleichzeitig für alles hinter dem Proxy.

Das ist jedoch nicht enthalten: die Identität innerhalb der Anwendung. Die Anwendung hat weiterhin eigene Konten und eine eigene Vorstellung davon, wer angemeldet ist. Wenn alle den Proxy passieren und in einem gemeinsamen Administratorkonto landen, haben Sie eine sichere Eingangstür, aber dahinter eine anonyme Sitzung. Im Audit-Log wird weiterhin nur ein einziger Name angezeigt. Berechtigungen können weiterhin nicht zwischen Personen unterschieden werden. Diese Konfiguration als SSO zu bezeichnen, ist ein Sicherheitsfehler, weil das Offboarding nur zur Hälfte funktioniert: Wenn Sie die Person aus Ihrem IdP entfernen, schließen Sie die Eingangstür. Ein API-Token, das sie innerhalb der Anwendung erstellt hat, funktioniert jedoch weiterhin für jeden, der die Anwendung direkt erreichen kann.

Header-Authentifizierung sicher machen

Einige Anwendungen akzeptieren einen Benutzernamen vom Proxy. Damit erhalten Sie eine benutzerbezogene Identität ohne kostenpflichtiges SSO. Die Einstellung hat in jedem Projekt einen anderen Namen.

Grafana nennt diese Funktion Auth-Proxy und liefert sie standardmäßig deaktiviert aus. Der Headername ist standardmäßig X-WEBAUTH-USER. Sie können dort jeden Header festlegen, den Ihr Proxy setzt.

[auth.proxy]
enabled = true
header_name = X-authentik-username
header_property = username
auto_sign_up = true
whitelist = 10.0.0.5

whitelist ist die Zeile, die häufig übersprungen wird. Die Dokumentation von Grafana weist ausdrücklich darauf hin, dass diese Einstellung das Spoofing des Headers verhindert. Sie darf daher ausschließlich die Adresse Ihres Proxys enthalten. Gitea bietet dieselbe Funktion unter anderen Namen an und verwendet dafür standardmäßig eine sicherere Einstellung.

[security]
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
REVERSE_PROXY_AUTHENTICATION_USER = X-WEBAUTH-USER
REVERSE_PROXY_TRUSTED_PROXIES = 10.0.0.5/32
REVERSE_PROXY_LIMIT = 1

REVERSE_PROXY_TRUSTED_PROXIES ist standardmäßig auf 127.0.0.0/8,::1/128 gesetzt. REVERSE_PROXY_LIMIT legt fest, wie vielen Proxys Gitea in der Kette vertraut. Wenn Sie diesen Wert auf null setzen, wird die Verarbeitung des Headers vollständig deaktiviert.

Paperless-ngx bietet PAPERLESS_ENABLE_HTTP_REMOTE_USER zusammen mit PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME an. In der Dokumentation steht dazu die Warnung, die für alle diese Einstellungen gilt:

Damit wird die Authentifizierung allein durch Hinzufügen eines Remote-User: <username>-Headers zu einer Anfrage ermöglicht. Verwenden Sie diese Funktion mit Vorsicht!

Zwei Regeln sorgen für eine sichere Header-Authentifizierung. Beide betreffen die Erreichbarkeit. Erstens darf die Anwendung nur über den Proxy erreichbar sein. Jeder, der eine Socket-Verbindung zu ihr öffnen kann, kann den Header senden und sich als beliebiger Benutzer anmelden. In Docker veröffentlicht ports: ["8000:8000"] den Port auf allen Schnittstellen. Binden Sie ihn daher mit ports: ["127.0.0.1:8000:8000"] an die Loopback-Adresse. Alternativ können Sie den veröffentlichten Port entfernen und den Proxy in dasselbe Docker-Netzwerk aufnehmen. Zweitens muss der Proxy jede Kopie des Headers löschen, die vom Client eingeht. Die Anwendung darf nur den Wert sehen, den Ihr Proxy nach der Authentifizierung setzt.

Prüfen Sie beides. Führen Sie den ersten Befehl auf einem Rechner außerhalb Ihrer VPS aus und den zweiten direkt auf dem Server.

curl -si -H "Remote-User: admin" http://203.0.113.10:8000/ | head -n 1
ss -ltnp | grep 8000

Der curl-Befehl sollte keine Verbindung herstellen können. ss sollte 127.0.0.1:8000 statt 0.0.0.0:8000 ausgeben. Eine erste Zeile mit HTTP/1.1 302 Found bedeutet, dass die Anwendung direkt aus dem öffentlichen Internet erreichbar ist. Dann kann sich jeder als beliebiger Benutzer anmelden, indem er dessen Namen in einem Header angibt.

Wenn kein kostenloses SSO verfügbar ist, treffen Sie eine Entscheidung, statt sich zu beschweren

Vier Optionen, in der Reihenfolge, in der ich sie ausprobieren würde.

1. Wählen Sie die Anwendung, die OIDC unterstützt. Wenn zwei Projekte dieselbe Aufgabe erfüllen und eines davon kostenlos mit Ihrem Identity Provider kommuniziert, ist das ein echter Unterschied bei den Betriebskosten.
2. Verwenden Sie Forward Auth bewusst. Für ein Administrationswerkzeug mit einem Konto und einem einzigen Operator reicht ein vorgeschalteter Proxy aus. Eine Benutzeridentität innerhalb der Anwendung bietet in diesem Fall keinen zusätzlichen Nutzen.
3. Bezahlen Sie. Wenn die Anwendung für Ihre Arbeit zentral ist und der Preis pro Benutzer zu Ihrer Teamgröße passt, trägt das Geld zur Wartung des Projekts bei. Die Alternative bezahlen Sie mit Ihrer Freizeit.
4. Fragen Sie beim Upstream-Projekt nach, nachdem Sie den Issue Tracker durchsucht haben. Die OIDC-Unterstützung für Vaultwarden entstand über den Fork eines Contributors und einen lang laufenden Pull Request. Eine Feature-Anfrage mit einer funktionierenden Implementierung kann daher manchmal auch in der kostenlosen Edition übernommen werden.

Nichts davon funktioniert ohne einen eigenen Identity Provider. Dieser sollte zuerst eingerichtet werden. authentik auf einem VPS betreiben stellt Ihnen einen OIDC- und SAML-Provider sowie den oben verwendeten Forward-Auth-Outpost bereit. Der Vergleich von Keycloak, authentik und Zitadel erläutert die jeweiligen Kompromisse, falls Sie sich noch nicht festlegen möchten.

Lizenzhistorie und warum sie auf der Checkliste steht

Der letzte Punkt der Checkliste betrifft die Zukunft, denn die heutige Einordnung in Lizenzstufen ist nur eine Momentaufnahme. Zwei gut dokumentierte Fälle zeigen, wie schnell sich die Rahmenbedingungen in beide Richtungen ändern. HashiCorp führte am 10 August 2023 für alle künftigen Releases die Business Source License 1.1 ein, während frühere Releases unter der MPL 2.0 (Mozilla Public License) blieben. Redis wechselte im March 2024 zur SSPL (Server Side Public License) und kündigte anschließend am 1 May 2025 an, dass Redis 8 auch unter der AGPLv3 (GNU Affero General Public License) veröffentlicht wird.

Betrachten Sie beide Fälle als Beleg für den Mechanismus, nicht für die Motive. Die Lizenz, die Sie heute lesen, gilt für die Version, die Sie heute installieren. Ein Projekt, das sämtliche Urheberrechte hält, kann die Bedingungen für das nächste Release selbst ändern. Deshalb steht die CLA-Frage auf der Checkliste: Eine umfassende Übertragung der Urheberrechte ermöglicht eine einseitige Änderung der Lizenz.

Prüfen Sie die Historie eines Projekts selbst, bevor Sie darauf aufbauen.

git clone --filter=blob:none https://github.com/paperless-ngx/paperless-ngx.git
cd paperless-ngx
git log --follow --oneline -- LICENSE

Eine kurze Liste von Commits, die größtenteils aus dem ersten Import stammen, ist ein gutes Zeichen. Mehrere Überarbeitungen der Lizenzdatei bedeuten, dass Sie jede Commit-Nachricht lesen sollten, bevor Sie Ihre Planung auf die aktuellen Bedingungen stützen.

FAQ

Was ist die SSO-Steuer?

Die SSO-Steuer bezeichnet die Praxis, Single Sign-on als Premiumfunktion zu berechnen, obwohl das restliche Produkt kostenlos oder günstig ist. Bei selbst gehosteter Software zeigt sich das beispielsweise als Open-Source-Anwendung, die ohne Lizenzschlüssel betrieben werden kann, während die Anmeldung über OIDC oder SAML einer kostenpflichtigen Tarifstufe vorbehalten ist. Der Name stammt von der SSO Wall of Shame auf sso.tax, die Anbieter erfasst, die dafür einen hohen Aufpreis verlangen. Für Betreiber selbst gehosteter Software bedeutet das, dass jede Anwendung ihre eigene Benutzerdatenbank behält. Konten müssen daher manuell angelegt und entfernt werden.

Ist ein Reverse Proxy mit Forward Auth dasselbe wie SSO?

Nein. Forward Auth schützt den Zugangspunkt: Der Proxy prüft beim Identity Provider, bevor eine Anfrage die Anwendung erreicht. Die dahinterliegende Anwendung verwendet weiterhin ihre eigenen Konten. Wenn alle Benutzer bei einer gemeinsamen Anmeldung landen, erhalten Sie daher eine einzige anonyme Sitzung und ein Audit-Log mit nur einem Namen. Eine echte Identität pro Benutzer entsteht erst, wenn die Anwendung den Benutzernamen aus einem Header liest. Das können beispielsweise Grafanas Auth Proxy, Giteas Reverse-Proxy-Authentifizierung und Paperless-ngx mit PAPERLESS_ENABLE_HTTP_REMOTE_USER. Diese Einstellungen sind nur sicher, solange die Anwendung ausschließlich über den Proxy erreichbar ist. Der Header ist eine einfache Zeichenkette, die jeder Client senden kann.

Welche selbst gehosteten Anwendungen enthalten OIDC in der kostenlosen Edition?

Abgleich mit der Projektdokumentation im August 2026: Paperless-ngx, Planka, BookStack, Gitea, listmonk und Vaultwarden unterstützen OIDC in ihren kostenlosen Builds. GitLab Self-Managed führt SAML unter „Tier: Free“. Grafanas Open-Source-Build unterstützt generisches OAuth mit einem eigenen Issuer. SAML ist dort dagegen eine Enterprise-Funktion. Prüfen Sie vor der Installation die Authentifizierungsseite des jeweiligen Projekts, da sich diese Listen mit neuen Releases ändern.

Sollte ich die Tarifstufe bezahlen, die Single Sign-on freischaltet?

Treffen Sie die Entscheidung anhand von zwei Zahlen: Wie viele Personen benötigen Konten, und wie viele Anwendungen müssten Sie andernfalls manuell verwalten? Für eine oder zwei Administratoren reicht Forward Auth vor einem lokalen Konto aus. Die kostenpflichtige Tarifstufe bietet dann nur wenige Vorteile. In einem Team, in dem Personen hinzukommen und ausscheiden, kann ein beim Offboarding übersehenes Konto mehr kosten als die Lizenz. Die Zahlung finanziert außerdem die Wartung, auf die Sie angewiesen sind. Wenn der Preis nicht passt, wählen Sie am besten eine Anwendung mit OIDC, statt eine Anwendung ohne diese Funktion mit Umgehungslösungen zu betreiben.