Single Sign-on (SSO).

Bei Single Sign-on gibt es einen zentralen Ort, an dem die Anmeldung stattfindet: den Identitätsanbieter, oft Identity Provider oder kurz IdP genannt. In vielen Unternehmen ist das Microsoft Entra ID (früher Azure AD) oder Google Workspace. Jede angeschlossene Anwendung, etwa das CRM, die Zeiterfassung oder ein internes Portal, verzichtet auf eine eigene Passwortverwaltung und leitet beim Anmelden an diesen Identitätsanbieter weiter. Ist die Person dort schon angemeldet, kommt sie ohne weitere Eingabe zurück und ist auch in der Anwendung angemeldet.

Technisch stehen dahinter vor allem zwei Standards. SAML 2.0 ist der ältere, XML-basierte Standard, der in Unternehmenssoftware weit verbreitet ist. OpenID Connect baut auf OAuth 2.0 auf, arbeitet mit JSON und ist bei moderneren Web- und Mobile-Anwendungen üblich. Beide erreichen dasselbe Ziel: Die Anwendung erhält eine signierte Bestätigung, wer die Person ist und welche Gruppen oder Rollen sie hat, ohne je ein Passwort zu sehen.

Der Nutzen ist doppelt. Für Mitarbeitende fällt der Alltag mit einem Dutzend Passwörtern weg. Für das Unternehmen ist die Sicherheit zentral steuerbar: Zwei-Faktor-Authentifizierung oder Passkeys werden einmal beim Identitätsanbieter verlangt und gelten für alle Anwendungen. Und wenn jemand das Unternehmen verlässt, wird ein einziges Konto gesperrt, statt in zehn Systemen einzeln nach Zugängen zu suchen. Gerade dieser letzte Punkt wird in KMU oft unterschätzt, bis ein ehemaliger Zugang noch Monate später aktiv ist.

SSO hat auch Grenzen. Der Identitätsanbieter wird zu einem zentralen Ausfallpunkt: Ist er nicht erreichbar oder wird ein Konto dort kompromittiert, betrifft das alle angeschlossenen Systeme. Deshalb gehört eine starke Absicherung genau dieses Kontos zur Pflicht. Ausserdem unterstützt nicht jede Software SSO, oder sie bietet es nur in teuren Paketen an. Bei eigener Software, etwa einer Web-App oder einem CRM, lässt sich SSO dagegen von Anfang an einplanen.