Mit Single Sign-On (SSO) melden sich Recruiter, Hiring Manager und Account Manager einmal über den zentralen Identity Provider ihres Unternehmens an, etwa über Microsoft Entra ID oder Google Workspace. Danach greifen sie ohne eigenes Passwort auf das Bewerbermanagementsystem (ATS) zu. Für Personalabteilungen und Personalvermittlungen bedeutet das weniger Passwortverwaltung, ein schnelleres Onboarding und Offboarding und eine nachvollziehbare Zugriffskontrolle. Dieser Leitfaden erklärt, wie die Anmeldung technisch abläuft, welcher Standard zu Ihrer Umgebung passt, was Sie vor der Einrichtung klären sollten und wie Webhooks das ATS sicher mit Ihren übrigen Systemen verbinden.

Kurz gesagt

• SSO verlagert die Anmeldung aus dem ATS zu einem zentralen Identity Provider (IdP). Das ATS prüft keine Passwörter mehr, sondern vertraut der Bestätigung des IdP.

• SAML 2.0 und OpenID Connect sind die beiden gängigen Standards. OAuth 2.0 allein regelt Zugriffsrechte, nicht die Anmeldung.

• Beide Systeme müssen denselben Nutzer eindeutig erkennen, meist über die E-Mail-Adresse oder eine unveränderliche Benutzer-ID. Diese Zuordnung sollten Sie vor der Einrichtung festlegen.

• SSO ersetzt kein Rollenmanagement. Wer was im ATS sehen darf, regeln weiterhin Rollen und Berechtigungen, die regelmäßig geprüft werden müssen.

• Webhooks melden Recruiting-Ereignisse wie neue Bewerbungen oder Statuswechsel in Echtzeit an andere Systeme. Sicher sind sie nur mit Signaturprüfung, Wiederholungslogik und Schutz vor Duplikaten.

Inhaltsverzeichnis

• 1. Was Single Sign-On in einem Bewerbermanagementsystem bedeutet

• 2. So läuft die Anmeldung zwischen ATS und Identity Provider ab

• 3. SAML 2.0, OpenID Connect und OAuth 2.0 im Vergleich

• 4. Voraussetzungen: SSO-ID, Attribute und Benutzerkonten

• 5. SSO im ATS einrichten: der Ablauf in sieben Schritten

• 6. Vorteile, Risiken und Schutzmaßnahmen

• 7. ATS-Webhooks: Recruiting-Ereignisse in Echtzeit weitergeben

• 8. Webhooks sicher einrichten und typische Fehler vermeiden

• 9. Unsere Perspektive: Zugang und Integration gehören zusammen

• 10. Recruitify: Recruiting, Vertrieb und Contracting in einem System

• Häufige Fragen

• Quellen

1. Was Single Sign-On in einem Bewerbermanagementsystem bedeutet

Ein ATS enthält einige der sensibelsten Daten eines Unternehmens: Lebensläufe, Gehaltsvorstellungen, Interviewnotizen, Gesundheitshinweise in Anschreiben und bei Agenturen zusätzlich Kundendaten und Vertragskonditionen. Gleichzeitig arbeiten viele Personen mit dem System, die nicht ständig darin eingeloggt sind: Fachbereichsleiter, die eine Shortlist bewerten, Interviewer, die Feedback hinterlegen, oder externe Freelancer, die für ein Projekt mitarbeiten.

Ohne SSO hat jede dieser Personen ein eigenes Passwort für das ATS. Das führt zu bekannten Problemen: wiederverwendete Passwörter, vergessene Zugänge, Konten ausgeschiedener Mitarbeitender, die noch Wochen später aktiv sind, und ein IT-Team, das Zugänge in mehreren Systemen getrennt pflegen muss.

Mit SSO übernimmt der Identity Provider die Identitätsprüfung. Das ATS agiert als sogenannter Service Provider (SP): Es fragt beim IdP nach, ob der Nutzer bereits authentifiziert ist, und erhält eine signierte Bestätigung zurück. Richtlinien wie Multi-Faktor-Authentifizierung, Passwortregeln oder Anmeldebeschränkungen nach Standort werden zentral im IdP definiert und gelten automatisch auch für das ATS.

Wichtig ist die Abgrenzung: SSO beantwortet die Frage „Wer ist diese Person?“. Die Frage „Was darf diese Person im ATS tun?“ beantwortet weiterhin das Berechtigungskonzept des ATS selbst.

2. So läuft die Anmeldung zwischen ATS und Identity Provider ab

In der Praxis gibt es zwei Einstiegswege, die Microsoft in seiner Dokumentation zum SSO-Modell als SP-initiiert und IdP-initiiert beschreibt.

SP-initiierte Anmeldung

Der Prozess beginnt im ATS. Ein typischer Ablauf sieht so aus:

1. Eine Recruiterin ruft die Anmeldeseite des ATS auf und gibt ihre geschäftliche E-Mail-Adresse ein oder klickt auf „Mit SSO anmelden“.

2. Das ATS erkennt die Domain und leitet sie an den konfigurierten Identity Provider weiter.

3. Der IdP prüft, ob bereits eine aktive Sitzung besteht. Falls nicht, fragt er Passwort und gegebenenfalls einen zweiten Faktor ab.

4. Der IdP sendet eine signierte Bestätigung mit Identitätsmerkmalen an das ATS zurück.

5. Das ATS prüft die Signatur, ordnet die Identität einem Benutzerkonto zu und öffnet die Sitzung.

IdP-initiierte Anmeldung

Hier startet der Nutzer im Portal des Identity Providers, etwa im Microsoft-My-Apps-Portal, und klickt auf die Kachel des ATS. Der IdP schickt die Bestätigung direkt an das ATS, ohne dass das ATS vorher angefragt hat. Dieser Weg ist bequem für Mitarbeitende, die ihren Arbeitstag ohnehin im Unternehmensportal beginnen.

Welcher Weg unterstützt wird, hängt vom ATS und vom Protokoll ab. Für Hiring Manager, die über einen Link in einer E-Mail-Benachrichtigung direkt zu einem Kandidatenprofil springen, ist die SP-initiierte Anmeldung entscheidend: Nur sie führt den Nutzer nach der Anmeldung zurück zur ursprünglich aufgerufenen Seite.

3. SAML 2.0, OpenID Connect und OAuth 2.0 im Vergleich

Die häufigste Verwirrung bei SSO betrifft die Protokolle. Laut Microsofts Entscheidungshilfe zu SAML und OpenID Connect ist SAML 2.0 ein ausgereiftes, XML-basiertes Verbundprotokoll, während OpenID Connect auf OAuth 2.0 aufbaut, JSON Web Tokens (JWT) verwendet und Benutzer anmeldet. OAuth 2.0 selbst regelt den Zugriff, nicht die Anmeldung.

Für die Auswahl gilt eine einfache Faustregel: Unterstützen sowohl Ihr IdP als auch das ATS beide Standards, ist OIDC bei neuen Einrichtungen und mobilem Zugriff oft unkomplizierter. SAML bleibt in vielen Konzernumgebungen der Standard, weil bestehende Richtlinien und Vorlagen darauf ausgerichtet sind. Entscheidend ist weniger das Protokoll als eine saubere Konfiguration und die Abstimmung mit Ihrer IT.

Der Unterschied zu OAuth wird im Recruiting-Alltag sichtbar: Wenn ein ATS auf den Kalender eines Recruiters zugreift, um Interviewtermine vorzuschlagen, ist das eine OAuth-Freigabe. Die Person meldet sich damit nicht am ATS an, sondern erlaubt dem ATS, in ihrem Namen auf einen anderen Dienst zuzugreifen. Wie solche Verknüpfungen in der Praxis aussehen, zeigt unser Beitrag zur Microsoft-Teams-Integration im Recruiting.

4. Voraussetzungen: SSO-ID, Attribute und Benutzerkonten

Der Begriff „SSO-ID“ wird uneinheitlich verwendet. Gemeint ist meist die eindeutige Kennung, über die Identity Provider und ATS einen Nutzer einander zuordnen. Bei SAML heißt dieses Merkmal NameID, bei OIDC ist es der sogenannte Subject-Claim. Je nach Konfiguration ist es die E-Mail-Adresse, der User Principal Name oder eine unveränderliche Objekt-ID aus dem Verzeichnis.

Wie Recruitmenttech.nl betont, müssen beide Systeme denselben Nutzer eindeutig erkennen können, und Organisationen sollten vorab festlegen, welche Informationen dafür nötig sind. In der Praxis sollten Sie vor der Einrichtung folgende Punkte klären:

1. Eindeutiges Merkmal: E-Mail-Adressen ändern sich bei Namenswechseln oder Umfirmierungen. Eine unveränderliche ID ist robuster, muss aber im ATS hinterlegt sein.

2. Übertragene Attribute: Vorname, Nachname, E-Mail, Abteilung, Standort und gegebenenfalls Gruppenzugehörigkeit. Übertragen Sie nur, was das ATS tatsächlich benötigt, im Sinne der Datenminimierung nach DSGVO.

3. Kontoanlage: Werden Konten bei der ersten Anmeldung automatisch angelegt (Just-in-Time-Provisioning), über einen Verzeichnisabgleich wie SCIM gepflegt oder manuell im ATS erstellt?

4. Bestehende Konten: Wie werden vorhandene Passwort-Konten mit der SSO-Identität verknüpft, ohne dass Duplikate entstehen?

5. Externe Nutzer: Freelancer, Kundenansprechpartner oder Interviewer anderer Gesellschaften sind oft nicht im eigenen Verzeichnis. Für sie brauchen Sie eine Gastregel oder einen separaten Zugang.

6. Notfallzugang: Mindestens ein Administratorkonto sollte auch bei einem Ausfall des IdP erreichbar bleiben, abgesichert durch starke Authentifizierung und dokumentiert.

5. SSO im ATS einrichten: der Ablauf in sieben Schritten

Die genauen Menüpunkte unterscheiden sich je nach ATS und IdP. Der Ablauf folgt aber fast immer demselben Muster:

1. Anforderungen sammeln: Welche Nutzergruppen sollen SSO verwenden, welches Protokoll unterstützen beide Seiten, und ist SSO im gebuchten Plan enthalten?

2. Anwendung im IdP anlegen: In Microsoft Entra ID oder Google Workspace wird das ATS als Unternehmensanwendung registriert.

3. Metadaten austauschen: Bei SAML tauschen Sie Entity-ID, Assertion-Consumer-Service-URL und Signaturzertifikat aus, bei OIDC Client-ID, Client-Secret und Redirect-URI.

4. Attribute zuordnen: Legen Sie fest, welches Feld die eindeutige Kennung liefert und welche weiteren Attribute übertragen werden.

5. Rollen abbilden: Entscheiden Sie, ob Gruppen im IdP automatisch Rollen im ATS zuweisen oder ob Rollen im ATS gepflegt werden.

6. Mit einer Pilotgruppe testen: Prüfen Sie SP- und IdP-initiierte Anmeldung, Deep Links aus Benachrichtigungen, mobile Anmeldung und das Verhalten beim Abmelden.

7. Ausrollen und Passwort-Login einschränken: Erst wenn alles funktioniert, deaktivieren Sie die Passwortanmeldung für die betroffenen Nutzer, mit Ausnahme des Notfallzugangs.

Planen Sie außerdem den Zertifikatswechsel ein. SAML-Signaturzertifikate laufen ab, und ein vergessenes Ablaufdatum führt dazu, dass sich plötzlich niemand mehr anmelden kann. Ein Kalendereintrag für die IT mit ausreichendem Vorlauf verhindert diesen vermeidbaren Ausfall.

6. Vorteile, Risiken und Schutzmaßnahmen

Was SSO im Recruiting konkret verbessert

• Schnelleres Onboarding: Neue Recruiter erhalten Zugriff, sobald ihr Konto im Verzeichnis angelegt ist.

• Sauberes Offboarding: Wird ein Konto im IdP deaktiviert, endet auch der Zugang zum ATS. Das ist bei Agenturen mit wechselnden Projektmitarbeitenden besonders relevant.

• Höhere Akzeptanz bei Hiring Managern: Wer kein zusätzliches Passwort braucht, gibt Feedback zu Kandidaten schneller ab.

• Einheitliche Sicherheitsrichtlinien: Multi-Faktor-Authentifizierung gilt automatisch für das ATS.

Wo die Risiken liegen

SSO bündelt den Zugang. Wird ein Konto beim Identity Provider kompromittiert, stehen dem Angreifer alle angebundenen Anwendungen offen, einschließlich des ATS mit seinen Kandidatendaten. Deshalb ist Multi-Faktor-Authentifizierung im IdP keine Option, sondern Pflicht. Ein zweites Risiko ist die Verfügbarkeit: Fällt der IdP aus, kann sich niemand anmelden, was den oben genannten Notfallzugang notwendig macht.

Ein drittes, oft unterschätztes Risiko betrifft die Berechtigungen. Laut Recruitmenttech.nl macht die Einführung von SSO regelmäßige Audits der Benutzerrollen und Berechtigungen im ATS nicht überflüssig, weil die Rechteverwaltung unabhängig von der Identitätsprüfung funktioniert. Ein Recruiter, der vom Team A ins Team B wechselt, behält sonst womöglich Einblick in die Kandidaten seines früheren Mandats. Wie ein strukturiertes Rollenmodell mit Lebenszyklus und Prüfroutinen aussieht, beschreibt unser Leitfaden zum Rollenmanagement mit RBAC.

Schutzmaßnahmen im Überblick

• Multi-Faktor-Authentifizierung für alle Nutzer im IdP erzwingen

• Sitzungsdauer im ATS an die Sensibilität der Daten anpassen

• Rollen und Berechtigungen mindestens quartalsweise prüfen

• Anmeldeereignisse protokollieren und mit dem Audit-Trail des ATS abgleichen

• Zertifikate und Client-Secrets mit Ablaufdatum dokumentieren

• Notfallkonto getrennt absichern und seine Nutzung protokollieren

7. ATS-Webhooks: Recruiting-Ereignisse in Echtzeit weitergeben

SSO verbindet Menschen mit dem ATS. Webhooks verbinden das ATS mit anderen Systemen. Ein Webhook ist eine Benachrichtigung, die das ATS automatisch an eine festgelegte URL sendet, sobald ein bestimmtes Ereignis eintritt. Statt dass ein Zielsystem alle paar Minuten nachfragt, ob es Neuigkeiten gibt, meldet sich das ATS von selbst.

Typische Ereignisse im Recruiting sind:

• Eine neue Bewerbung geht ein

• Ein Kandidat wechselt in eine neue Pipeline-Phase, etwa von „Interview“ zu „Angebot“

• Ein Interview wird geplant, verschoben oder abgesagt

• Ein Angebot wird angenommen und die Einstellung bestätigt

• Ein Kandidatenprofil wird gelöscht oder anonymisiert

Der Nutzen zeigt sich in den Folgeprozessen: Die Zusage löst im HR-System die Anlage der Personalakte aus, ein Teamkanal erhält eine Nachricht zum neuen Kandidaten, das Controlling bekommt Daten für das Reporting, und bei Agenturen kann ein Vermittlungserfolg direkt an Abrechnung oder CRM gehen. Wie Benachrichtigungen in Kollaborationstools den Hiring-Prozess beschleunigen, zeigt unser Beitrag zur Slack-Integration im Recruiting.

Ein Webhook enthält in der Regel eine JSON-Nachricht mit dem Ereignistyp, einem Zeitstempel, einer eindeutigen Ereignis-ID und den betroffenen Datensätzen oder Verweisen darauf. Ob Sie Webhooks selbst anbinden oder eine vereinheitlichte Schnittstelle nutzen, hängt von der Zahl Ihrer Zielsysteme und den Ressourcen Ihrer IT ab. Die Abwägung haben wir in unserem Artikel zu ATS-Integrationen: Inhouse oder Unified API aufbereitet.

8. Webhooks sicher einrichten und typische Fehler vermeiden

Webhooks sind einfach einzurichten, aber fehleranfällig im Betrieb. Die folgenden Punkte gehören zu jeder produktiven Anbindung.

Echtheit prüfen

Die Empfänger-URL ist im Internet erreichbar. Ohne Prüfung könnte jeder gefälschte Ereignisse einschleusen, etwa eine angebliche Einstellung. Gängige Praxis ist eine Signatur: Das ATS berechnet mit einem gemeinsamen geheimen Schlüssel einen HMAC-Wert über den Nachrichteninhalt und sendet ihn im Header mit. Der Empfänger berechnet denselben Wert und verwirft Nachrichten, die nicht übereinstimmen. Ergänzend schützt ein Zeitstempel in der Signatur vor wiederholt eingespielten alten Nachrichten. Die Übertragung selbst erfolgt ausschließlich über HTTPS.

Fehlgeschlagene Zustellungen abfangen

Ist das Zielsystem kurz nicht erreichbar, darf das Ereignis nicht verloren gehen. Seriöse Implementierungen wiederholen die Zustellung mit wachsenden Abständen. Auf Empfängerseite gilt: Bestätigen Sie den Eingang schnell mit einem Erfolgsstatus und verarbeiten Sie die Daten anschließend asynchron, etwa über eine Warteschlange. Wer erst nach langer Verarbeitung antwortet, riskiert Zeitüberschreitungen und damit unnötige Wiederholungen.

Doppelte Ereignisse vermeiden

Wiederholungen bedeuten, dass dasselbe Ereignis mehrfach ankommen kann. Speichern Sie deshalb die Ereignis-ID und verarbeiten Sie jede ID nur einmal. Dieses Prinzip heißt Idempotenz. Ohne sie entstehen doppelte Personalakten, doppelte Rechnungen oder zwei identische Teamnachrichten.

Reihenfolge nicht voraussetzen

Ereignisse können in anderer Reihenfolge eintreffen, als sie entstanden sind. Prüfen Sie den Zeitstempel oder laden Sie den aktuellen Stand des Datensatzes über die API nach, bevor Sie einen Status überschreiben.

Datenschutz mitdenken

Übertragen Sie im Webhook nur die Daten, die das Zielsystem wirklich braucht. Häufig genügt eine Kandidaten-ID, mit der das Zielsystem die Details über die authentifizierte API abruft. So landen keine vollständigen Lebensläufe in Protokollen oder Fehlermeldungen. Ereignisse zu Löschung und Anonymisierung sollten ebenfalls weitergegeben werden, damit nachgelagerte Systeme keine Daten behalten, die im ATS bereits entfernt wurden.

9. Unsere Perspektive: Zugang und Integration gehören zusammen

In Gesprächen mit Personalvermittlungen und HR-Teams sehen wir immer wieder dasselbe Muster: SSO wird als IT-Projekt behandelt, Webhooks als Entwicklerthema und Rollen als Verwaltungsaufgabe. Tatsächlich beschreiben alle drei denselben Kern, nämlich wer auf welche Kandidaten- und Kundendaten zugreift und wohin diese Daten fließen.

Besonders deutlich wird das bei Agenturen, die Recruiting und Vertrieb verbinden. Wenn ein Account Manager im CRM einen Deal pflegt und ein Recruiter parallel die Kandidaten-Pipeline bearbeitet, entstehen Informationsbrüche genau dort, wo Daten zwischen getrennten Systemen synchronisiert werden müssen. Jede zusätzliche Schnittstelle ist ein weiterer Punkt, an dem Ereignisse verloren gehen, doppelt ankommen oder Berechtigungen auseinanderlaufen.

Unser Ansatz ist deshalb, die Zahl der Übergaben zu reduzieren: ATS, Sales CRM und IT-Contracting in einem System, mit Rollenmanagement, vollständigem Audit-Trail und DSGVO-Anonymisierung. Integrationen bleiben wichtig, aber sie sollten dort ansetzen, wo ein Fremdsystem wirklich gebraucht wird, nicht dort, wo nur fehlende Funktionen überbrückt werden. Unsere Empfehlung: Prüfen Sie bei jeder ATS-Auswahl Anmeldung, Rollenmodell und Schnittstellen gemeinsam, statt sie nacheinander als getrennte Projekte zu behandeln.

- Recruitify Team

10. Recruitify: Recruiting, Vertrieb und Contracting in einem System

Wenn Sie Zugriffskontrolle und Integrationen vereinfachen möchten, lohnt sich ein Blick auf die Architektur Ihres Systems. Recruitify vereint ATS, Sales CRM und ein Modul für IT-Contracting und Body Leasing auf einer Plattform, ergänzt um Rollenmanagement, Audit-Trail, DSGVO-Anonymisierung, AI CV Parser, Contextual Matching und Recruiting-Automatisierung, die Workflows vom ersten Lead-Kontakt bis zum B2B-Vertrag abbildet.

Der Plan HR Team kostet 61 € pro Monat und Nutzer, der Plan Agency 67 € pro Monat und Nutzer, Enterprise wird individuell angeboten. Welche Anmeldeverfahren und Schnittstellen für Ihre Umgebung infrage kommen, klären Sie am besten direkt in einer Demo. Alle Details finden Sie auf der Preisseite von Recruitify, einen Überblick über die Plattform auf recruitify.ai. Für die strukturierte Bewertung mehrerer Systeme hilft Ihnen außerdem unser Leitfaden zur ATS-Auswahl sowie die Übersicht der wichtigsten ATS-Funktionen.

Häufige Fragen

Welche Anbieter stellen SSO für ein ATS bereit?

SSO wird nicht vom ATS selbst, sondern von einem Identity Provider bereitgestellt. In deutschen Unternehmen sind das häufig Microsoft Entra ID oder Google Workspace, daneben spezialisierte Identity-Plattformen. Das ATS muss den Standard unterstützen, den Ihr IdP nutzt, in der Regel SAML 2.0 oder OpenID Connect.

Was ist der Unterschied zwischen SSO und OAuth?

SSO ist ein Anmeldekonzept, das über Protokolle wie SAML 2.0 oder OpenID Connect umgesetzt wird. OAuth 2.0 regelt dagegen, welche Anwendung auf welche Daten zugreifen darf, etwa wenn ein ATS Ihren Kalender liest. OpenID Connect baut auf OAuth 2.0 auf und ergänzt die eigentliche Anmeldung.

Was bedeutet SSO-ID?

Mit SSO-ID ist meist die eindeutige Kennung gemeint, über die Identity Provider und ATS einen Nutzer zuordnen. Das kann die E-Mail-Adresse, der User Principal Name oder eine unveränderliche Objekt-ID sein. Legen Sie vor der Einrichtung fest, welches Merkmal beide Systeme verwenden.

Brauche ich mit SSO noch ein Rollenkonzept im ATS?

Ja. SSO prüft nur, wer sich anmeldet, nicht welche Kandidaten, Mandate oder Kundendaten die Person sehen darf. Rollen und Berechtigungen im ATS sollten Sie deshalb weiterhin regelmäßig prüfen, besonders nach Team- oder Projektwechseln.

Wie verhindere ich doppelte Webhook-Ereignisse?

Speichern Sie die eindeutige Ereignis-ID jeder Nachricht und verarbeiten Sie jede ID nur einmal. Bestätigen Sie den Eingang schnell und verarbeiten Sie die Daten danach asynchron, damit keine unnötigen Wiederholungen ausgelöst werden. Prüfen Sie zusätzlich die Signatur, damit nur echte Nachrichten des ATS verarbeitet werden.

Quellen

• Microsoft Learn: Grundlegendes zum SSO-Modell von Microsoft

• Microsoft Learn: SAML im Vergleich zu OpenID Connect

• Recruitmenttech.nl: Hoe werkt Single Sign-On als integratie met een ATS?

Empfehlungen

• ATS-Integrationen für Recruiter: Inhouse oder Unified API wählen

• Verhindere Doppelarbeit: Implementiere ein ATS für HR-Teams und Agenturen

• Kein Kandidat geht beim Wechsel des ATS-Systems verloren: 6 Schritte für Recruiter

• ATS-Funktionen: Was ein Bewerbermanagementsystem heute leisten muss