Wie man einen Identity Provider auswählt: Das Bewertungsframework des Engineering-Teams

Die meisten Vergleichsartikel zu Identity Providern werden von den Anbietern selbst geschrieben. Überraschend, oder? Sie listen Features auf, die ihr Produkt hat, verschweigen die, die fehlen, und bezeichnen das Ganze als "objektiven Leitfaden".

Das hier ist anders.

Wir haben Dutzende echte Bewertungsanfragen aus Unternehmen geprüft — die tatsächlichen Tabellen und RFP-Dokumente, die Beschaffungsteams an Anbieter schicken. Die Muster sind klar: Engineering-Teams gewichten konsequent die wichtigsten Kriterien zu gering und die am wenigsten wichtigen zu stark.

Das Ergebnis? Teams wählen einen IdP anhand einer Demo aus, merken nach sechs Monaten, dass die Migration eine Katastrophe ist, und beginnen erneut mit der Evaluation.

Hier ist das Bewertungsframework, das wir gerne selbst vorab bekommen hätten. Es ist für Engineering-Teams in B2B SaaS-Unternehmen gedacht — die, die Produkte bauen, nicht die, die Workforce-SSO für ihre Mitarbeiter einkaufen.

Kurze Antwort: Was macht die Entscheidung für einen IdP aus oder zerstört sie?#

Falls du nur querliest, hier die Kurzfassung:

1. Die Tiefe des Protokolls ist wichtiger als die Anzahl der Features. Zu sagen "OAuth2 wird unterstützt" bedeutet gar nichts. Welche Grant Types? Kann man Token-Claims anpassen? Kannst du selbst zum OIDC-Provider werden?
2. Migrationsfähigkeit ist das am meisten unterschätzte Kriterium. Wenn du keine Bestandsnutzer ohne Passwort-Reset migrieren kannst, ist der IdP unbrauchbar — egal wie gut alles andere aussieht.
3. Multi-Tenancy muss nativ sein, nicht angeflanscht. Wenn Organisationsmodelle und tenant-spezifische Konfigurationen Workarounds benötigen, kämpfst du endlos gegen das System.
4. KI-Readiness ist keine Zukunftsplanung — sondern eine Anforderung innerhalb von 12 Monaten. Token Exchange, Agent Identity, Delegated Scopes. Wenn der IdP das nicht unterstützt, stehst du nächstes Jahr wieder bei der Evaluierung.

Der Rest des Leitfadens führt durch jede Bewertungsdimension im Detail, mit konkreten Fragen und Warnsignalen.

Für wen dieser Leitfaden gedacht ist (und für wen nicht)#

Das ist für dich, wenn:

• Du CTO, VP of Engineering oder Plattformarchitekt eines B2B SaaS-Unternehmens mit 50-300 Mitarbeitern bist
• Du mehr als 100.000 Bestandsnutzer hast und keine aufwühlende Migration erlauben kannst
• Du in den Enterprise-Bereich expandierst und deine Kunden SSO, Organisationsmodelle und Audit-Logs benötigen
• Du einen technischen Evaluierungsbericht schreiben musst und ein Framework willst, das nicht von einem Anbieter stammt

Das ist NICHT für dich, wenn:

• Du Workforce-IAM suchst (Mitarbeiter-SSO für interne Tools) — das ist eine andere Kaufentscheidung
• Du ein Startup mit 500 Nutzern und noch keinen Unternehmenskunden bist — nimm, was das beste SDK hat, und mach weiter
• Du Identitätsprüfung (KYC/KYB) brauchst — das ist eine komplett andere Kategorie

Dimension 1: Protokollfähigkeiten — Nicht nur "supports OAuth2"#

Jeder IdP auf dem Markt wird behaupten, OAuth2 und OIDC zu unterstützen. Das ist das absolute Minimum. Die wirklichen Fragen betreffen die Tiefe.

Grant Types: Welche und warum sie wichtig sind#

Unverzichtbar:

• Authorization Code + PKCE — Der einzige Flow, den du für Browser- und Mobile-Apps nutzen solltest. Wenn ein Anbieter noch Implicit Flow empfiehlt, geh weiter. PKCE ist kein optionales Feature, sondern ein Sicherheitsstandard.
• Client Credentials — Für Service-to-Service-Kommunikation. Deine Backend-Services müssen sich gegenseitig ohne Nutzer authentifizieren.
• Refresh Token — Hört sich einfach an, aber die Implementierungen unterscheiden sich extrem. Kannst du Rotation konfigurieren? Ablauf einstellen? Einen bestimmten Refresh Token widerrufen, ohne die gesamte Session zu zerstören?

Immer wichtiger:

• Token Exchange (RFC 8693) — Das ist der Grant Type, der KI-Agenten-Authentifizierung, Impersonation-Flows und Delegation ermöglicht. Wenn das heute fehlt, frage nach der Roadmap. Gibt es keine, ist das ein Warnsignal.

OIDC Provider-Fähigkeit#

Eine Frage, die die meisten Teams nie stellen: Kannst du diesen IdP als OIDC Provider einsetzen — und nicht nur als OIDC-Konsument?

Warum das relevant ist: Wenn dein SaaS wächst, möchten Partner und Kunden womöglich dein Identitätssystem nutzen, um sich in ihre eigenen Tools einzuloggen. Du musst Tokens ausstellen, Consent managen und Third-Party-App-Registrierung ermöglichen. Wenn dein IdP nur externe Provider konsumieren, aber nicht selbst einer sein kann, stößt du bei Outbound-Föderation an eine Wand.

Fragen:

• Bietet der IdP einen OpenID Discovery Endpoint, den du white-labeln kannst?
• Kannst du First-Party- und Third-Party-Apps mit unterschiedlichen Vertrauensstufen registrieren?
• Können First-Party-Apps die Consent-Screen überspringen, während Third-Party-Apps diesen benötigen?

JWT-Anpassung#

Das Token ist der Vertrag zwischen deinem IdP und deinen Diensten. Wenn du es nicht anpassen kannst, müssen nachgelagerte Services zusätzliche API-Calls machen, um herauszufinden, was ein Nutzer darf.

Fragen:

• Kannst du eigene Claims zu Access Tokens und ID Tokens hinzufügen?
• Kannst du den Organisationskontext (in welchem Tenant der Nutzer agiert) direkt ins Token einbetten?
• Kannst du eigene Scopes definieren, die zu deinem Berechtigungsmodell passen?
• Werden Claims beim Ausstellen des Tokens berechnet, oder lassen sie sich dynamisch per Webhook/Skript füllen?

Ein Token mit { "org_id": "org_123", "role": "admin", "auth_level": 2 } ermöglicht, dass dein API-Middleware mit einer Zeile eine Berechtigungsentscheidung trifft. Ein Token mit nur { "sub": "user_456" } zwingt jeden Dienst, zur IdP oder einer Datenbank zurückzurufen, um mehr herauszufinden. Im großen Stil macht das den Unterschied zwischen 2 ms und 200 ms pro Anfrage aus.

Dimension 2: Authentifizierungsflüsse — Die Details, die dich umbringen#

Jeder IdP beherrscht E-Mail/Passwort und Social Login. Glückwunsch, du hast... alle Anbieter auf der Liste.

Die Unterschiede stecken in den Details, die in Demos nie gezeigt werden.

Der Sign-up Flow#

• Post-Registrierung Auto-Login: Wird der Nutzer nach der Registrierung automatisch eingeloggt? Oder sieht er wieder die Login-Seite? Direkt nach der Registrierung einen Login zu erzwingen, kostet Conversion. Viele IdPs machen hier Fehler.
• Eigene Registrierungsfelder: Kannst du Rolle, Firmenname oder Use Case schon bei der Registrierung abfragen? Oder ist ein separater Onboarding-Prozess nötig?
• Progressive Profilierung: Kannst du zusätzliche Infos über mehrere Sessions einsammeln, statt alles sofort zu verlangen?

Der Login-Flow#

• login_hint-Support: Kannst du beim Klick aus einer Marketing-Mail die E-Mail-Adresse vorbefüllen? Klingt banal — ist es aber nicht. Das entscheidet über 40 % oder 60 % Conversion bei E-Mail-Kampagnen.
• Organisationsspezifische Auth-Policies: Kann Org A SAML-SSO verlangen, während Org B mit E-Mail/Passwort arbeitet? Kannst du MFA nur für Enterprise-Tenants erzwingen? Falls der Wechsel der Policies pro Tenant Code erfordert und nicht per Konfiguration möglich ist, verschwendest du Engineering-Zeit mit jedem neuen Kunden.
• Branding-Anpassung: Kannst du das Login-Erlebnis pro Tenant anpassen? Nicht nur Logo und Farbe — vollständige CSS-Kontrolle, eigene Domains und white-label E-Mails. "Hosted UI vs. eigenes UI" sollte deine Wahl sein, keine Restriktion des Anbieters.

Was die meisten Checklisten übersehen#

• Silent Authentication: Kann die App eine neue Session starten, wenn ein Token abläuft, ohne den Nutzer umzuleiten? Was passiert, wenn auch das Refresh Token abgelaufen ist — gibt es ein Fallback (z. B. eine gleitende Session per IFrame)?
• Account Linking: Nutzer meldet sich zuerst mit Google an, später mit E-Mail. Sind das zwei Accounts oder einer? Wie geht der IdP mit Identitätszusammenführung um? Wenn das schiefgeht, hast du endlos doppelte "Geister-Accounts".
• Passwordless-Optionen: Magic Links, Passkeys, WebAuthn. Nicht, weil du sie heute brauchst, sondern weil Unternehmenskunden spätestens in sechs Monaten danach fragen werden.

Dimension 3: Session- und Token-Management — Die Tiefe, in der man ersäuft#

Hier trennt sich im Test die Realität von der Demo. Session/Tokennmanagement ist langweilig, bis es Probleme macht — dann werden alle Nutzer gleichzeitig ausgeloggt.

Cookie-Sicherheit#

Nicht sexy. Absolut zentral.

• HttpOnly, Secure, SameSite Attribute: Alle drei müssen korrekt gesetzt sein. Kein IdP ohne HttpOnly auf Session-Cookies ist produktionsreif.
• Cross-Subdomain-Support: Wenn deine App auf app.deinprodukt.com und deine API auf api.deinprodukt.com läuft, können Sessions Subdomains überspannen? Wie genau?
• Abschaffung von Third-Party-Cookies: Chrome schafft sie ab. Wie unterstützt der IdP Cross-Origin-Auth-Flows ohne sie? "Wir arbeiten daran" reicht nicht.

Remember Me und persistente Sessions#

Deine Nutzer wollen Wochen lang eingeloggt bleiben, nicht Minuten. Eine Session über 180 Tage hat aber völlig andere Sicherheitsimplikationen als 30 Minuten.

Fragen:

• Kannst du Sitzungsdauer unabhängig von der Token-Lifetime konfigurieren?
• Gibt es eine "remember me"-Option, die die Session verlängert, aber Token kurzfristig hält?
• Kannst du für sensible Aktionen Re-Auth erzwingen, ohne die Session zu beenden?

Refresh-Token-Sicherheit#

• Token-Rotation: Rotiert der IdP Refresh Tokens bei jeder Benutzung? (Sollte er.)
• Verschlüsselte Speicherung: Sind Refresh Tokens im Speicher verschlüsselt?
• Widerruf-Granularität: Kannst du eine einzelne Gerätesession widerrufen, ohne alle zu beenden?
• Konfigurierbares Ablaufdatum: Verschiedene Apps brauchen verschiedene Refresh-Token-Lifetimes. Ist das pro Anwendung einstellbar oder nur global?

Dimension 4: Berechtigungsmodell — Mehr als reines RBAC#

Role-Based Access Control ist das Minimum. Ohne RBAC kein Kandidat. Im B2B SaaS reicht das aber nicht.

Organisationsbezogene Berechtigungen#

Deine Nutzer gehören zu Organisationen. Ihre Rechte innerhalb jeder Organisation sind andere als auf Plattformeebene.

Ein Nutzer kann Admin in Org A und Viewer in Org B sein — ein und derselbe Nutzer, aber verschiedene Rollen-Konte. Kann das IdP das nicht nativ abbilden, baust du ein Parallelsystem — und hast zwei Wahrheiten.

Fragen:

• Kannst du Rollen auf Organisationsebene statt nur auf Nutzerebene definieren?
• Kann ein Nutzer unterschiedliche Rollen in mehreren Organisationen haben?
• Ist der aktuelle Organisationskontext im Token eingebettet, sodass dein API weiß, für welche Organisation gehandelt wird?

Mehrstufige Autorisierung (auth_level)#

Für Finanzanwendungen, Gesundheit oder alles mit kritischen Vorgängen: Nicht jede Authentifizierung ist gleich sicher.

Dashboard anzeigen? Session-Cookie reicht. Eine Überweisung auslösen? Es braucht erneute MFA-Verifizierung, auch wenn der Nutzer eingeloggt ist.

Das ist Step-Up-Authentifizierung und benötigt Authentifizierungslevel (auth_level) als eigenständige Infos im Token-System.

Fragen:

• Kann das Token ein auth_level-Claim enthalten, das dein Backend prüft?
• Kannst du Step-Up-Authentifizierung auslösen, ohne einen vollständigen Re-Login zu erzwingen?
• Hat das auth_level ein eigenes Ablaufdatum, unabhängig von der Session?

Falls der IdP das nicht nativ kann, baust du dir das selbst — genau das, wofür du eigentlich einen IdP willst.

Tokenbasierte Berechtigungsentscheidungen#

Das Ideal: Dein Middleware liest Token, sieht Organisation, Rolle und auth level und entscheidet lokal — ohne externen Dienst.

Die Realität: Token sagt nur, wer ist der User; eine zweite API-Abfrage klärt die Berechtigungen.

So eine Zusatzabfrage verursacht Latenz, erzeugt Abhängigkeiten und Fehlerquellen. Bei 1.000 Requests pro Sekunde willst du keine Berechtigungsprüfung über das Netzwerk machen.

Dimension 5: Migration — Das entscheidende Kriterium#

Eine unangenehme Wahrheit: Die meisten IdP-Evaluierungen scheitern nicht daran, dass der neue IdP schlecht ist, sondern weil das Team seine Bestandsnutzer nicht migrieren kann.

Mit 100.000+ Nutzern ist Migration kein "nice to have" — es ist das ganze Projekt!

Drei Migrationsstrategien (und was der IdP unterstützen muss)#

1. Bulk-Import existierender Passwort-Hashes

Deine Nutzer haben Passwörter mit bcrypt, argon2 oder einem eigenen Verfahren gehasht. Kann der IdP diese Hashes übernehmen und gegen sie prüfen?

Falls ja: User loggen sich mit bestehendem Passwort ein, alles bleibt wie gewohnt. Bestes Szenario.

Falls nein: Alle Nutzer bekommen eine "Passwort-zurücksetzen"-Mail. Du verlierst 30-50 % der Nutzer bei der Migration. Kein Gerücht — schon erlebt.

2. Progressive (Lazy) Migration

Statt alles auf einmal migrierst du die Nutzer einzeln beim ersten Login. Erstes Login geht gegen das Altsystem. Bei Erfolg wird der Account im neuen IdP angelegt. Ab dann läuft immer alles über den neuen IdP.

Das ist der sicherste Ansatz für große Nutzerbasen, aber er erfordert:

• Einen Authentifizierungs-Hook, der dein Legacy-System aufruft
• Die Fähigkeit, einen Nutzer im Login-Prozess on-the-fly anzulegen
• Das Tracking der schon migrierten vs. noch nicht migrierten Nutzer

3. Dual-Write (Betrieb beider Systeme in Parallel)

Während der Übergangsphase laufen beide Identitätssysteme parallel. Neue Anmeldungen schreiben in beide, nach und nach gehen die Abfragen nur noch an das neue System. Das bietet eine Rollback-Möglichkeit, ist aber komplex in der Operation.

Migrations-Warnzeichen#

• "Wir unterstützen CSV-Import" — Bedeutet: Massenimport von Profilen, aber nicht von Passwörtern. Du brauchst trotzdem Passwortresets.
• "Wir haben einen Migrationsleitfaden" — Lies genau. Wenn da steht "Nutzer müssen ein neues Passwort wählen", drohen dir 30-50 % Verluste.
• Keine Erwähnung von Hash-Kompatibilität — Hat der Anbieter keinen Support für Passworthash-Migration, kennt er große Projekte nicht.

Fragen an den Anbieter#

• Welche Passworthash-Algorithmen unterstützt ihr beim Import? (bcrypt, argon2, scrypt, PBKDF2, custom?)
• Unterstützt ihr progressive Migration (Nutzer zieht beim ersten Login um)?
• Können wir den Fortschritt nachverfolgen — wieviel Prozent sind schon migriert?
• Was ist die Rollback-Strategie, falls Migration scheitert?
• Bleibt die Session-Kontinuität erhalten — damit Nutzer nicht ausgeloggt werden?

Wenn der Anbieter hier keine sicheren Antworten hat, haben sie das noch nie gemacht. Weitermachen.

Dimension 6: Multi-Tenancy — Native vs. angeflanscht#

B2B SaaS bedeutet Multi-Tenancy. Deine Kunden sind Organisationen mit mehreren Nutzern, Rollen und Berechtigungsrichtlinien. Der IdP muss das nativ verstehen.

Was "native Multi-Tenancy" bedeutet#

• Organisation als eigenständige Entität: Kein Custom Field im User-Profil, sondern ein eigenes Datenmodell mit ID, Konfiguration und Mitgliedern.
• Tenant-spezifische Authentifizierungsrichtlinien: Org A nutzt SAML-SSO mit eigenem IdP. Org B braucht E-Mail/Passwort und MFA. Org C loggt sich via Google Workspace ein. Alles per UI oder API konfigurierbar, kein Code nötig.
• Organisationseinladungen und Mitgliederverwaltung: Admins jeder Org können Nutzer einladen, Rollen verteilen, Mitglieder entfernen. Der IdP übernimmt Einladung, E-Mail-Verifizierung und Rollenvergabe.
• Tenant-Scoped Tokens: Wenn ein Nutzer für eine Organisation handelt, enthält das Token den Org-Kontext. Dein API weiß, welche Daten auszuliefern sind.

Der "Custom Metadata"-Workaround#

Manche IdPs haben kein natives Organisationsmodell. Sie empfehlen, Custom User Metadata (user.app_metadata.org_id = "123") als Workaround zu nutzen.

Das bricht schnell:

• Nutzer in mehreren Orgs — Array-Management im Metadata nötig
• Kein Einladungs- oder Mitglieder-Flow enthalten
• Keine tenant-spezifischen Auth-Policies
• Keine Organisationstoken — Kontext muss aus anderen Daten erraten werden
• Audits kennen keine Organisationen

Wenn der Anbieter sagt "Organisationen über unsere Metadata-Felder abbilden", ist das wie relationale Daten im JSON-Blob zu speichern. Funktioniert, bis es nicht mehr geht.

Fragen an den Anbieter#

• Ist das Organisationsmodell nativ oder auf User-Metadata gebaut?
• Können Nutzer mehreren Organisationen gleichzeitig angehören?
• Lassen sich Authentifizierungsanforderungen pro Organisation konfigurieren?
• Werden tenant-spezifische Rollen/Berechtigungen nativ unterstützt?
• Können Org-Admins Mitglieder via Self-Service-UI verwalten?
• Enthält das Token den Organisationskontext?

Dimension 7: KI-Readiness — Das Kriterium, das bisher niemand fragt#

Vor zwölf Monaten stand "KI-Agenten-Authentifizierung" in keiner Checkliste. Jetzt, wo KI-Features — Copilots, autonome Agenten, KI-Workflows — entwickelt werden, braucht dein IdP eine neue Identität: den Agenten.

Warum Agenten das Modell sprengen#

Klassische Authentifizierung hat zwei Akteure: Nutzer und Anwendung. OAuth2 wurde dafür gebaut.

KI-Agenten fügen einen dritten hinzu: Eine nicht-menschliche Entität, die im Namen eines Nutzers mit eingeschränkten Rechten agiert und eigene Audit-Datenspur braucht.

• Ein Agent ist kein Nutzer — hat kein Passwort, keine Session
• Ein Agent ist kein echter M2M-Service — agiert für einen Nutzer
• Ein Agent braucht begrenzte, zeitlich beschränkte Berechtigungen — nicht vollen User-Access

Was dein IdP unterstützen muss#

Token Exchange (RFC 8693): Der Agent legt eigenes Credential plus Nutzergenehmigung vor und bekommt ein eingeschränktes Token. Das Token trägt: Wer (Nutzer), Was (Agent), Scope (Berechtigungsgrenze), Wann (Ablauf).

Agent als Client-Type: Der Agent muss als echter OAuth2-Client mit client_id modelliert werden, nicht als Hack mit API-Key oder geteiltem Benutzertoken.

Delegierte Scope-Verwaltung: Der Nutzer kann dem Agenten gezielt Rechte geben — z. B. nur Lesen, nur bestimmte Ressourcen.

Audit-Differenzierung: Deine Logs müssen unterscheiden, ob "Nutzer machte X" oder "Agent machte X im Auftrag eines Nutzers". Ohne das fällst du beim nächsten SOC2-Audit durch.

MCP (Model Context Protocol)-Kompatibilität#

MCP ist im Begriff, Standardprotokoll für KI-Agenten-Anbindung zu werden. Unterstützt dein IdP OAuth-Auth für MCP-Server, können KI-Agenten sauber authentifiziert werden — nicht über Keys oder geteilte Secrets.

Fragen an den Anbieter#

• Unterstützt ihr OAuth2 Token Exchange?
• Können Agenten als eigener Client-Typ modelliert werden?
• Können Tokens Delegations-Infos tragen (wer autorisierte, welchen Scope)?
• Unterscheiden Audit-Logs Agentenaktionen von Nutzereingriffen?
• Gibt es MCP-Server-Integration oder OAuth für Agent-zu-Tool-Auth?

Wenn der Anbieter darüber noch nicht nachgedacht hat, baut er für 2020 — du planst für 2026.

Dimension 8: Nichtfunktionale Anforderungen — Die Themen, die dich nachts wach halten#

Features verkaufen. Der Betrieb entscheidet über die Vertragsverlängerung.

Performance#

• Authentifizierungsdurchsatz: Stemmt das System > 100 Anfragen/s zu Spitzenzeiten? Oder 1.000+?
• JWT-Validierungs-Latenz: Prüfen deine Services JWTs lokal (wie sie sollten), ist das sub-ms; erfordert der IdP introspection calls, wie ist dann die P99-Latenz?
• Scale-Limit: Wieviel MAUs werden maximal unterstützt? Gibt es Beispiele auf deinem Zielniveau?

Compliance#

• SOC2 Typ II: Nicht nur Typ I. Typ II heißt, es gab eine mehrmonatige Prüfung — nicht nur einen Tag. Wenn nur Typ I: Nach Zeitplan für Typ II fragen.
• Audit-Logs: Jedes Auth-Event, jede Berechtigungsänderung, jede Admin-Aktion geloggt. Kannst du diese ins SIEM exportieren? Sind sie unveränderbar?
• Data Residency: Kannst du angeben, in welcher Region Nutzerdaten liegen? Für EU-Kunden Pflicht.

Zuverlässigkeit#

• Uptime SLA: 99,9% klingt gut, sind aber 8,7 Stunden Ausfallzeit pro Jahr. 99,99% sind 52 Minuten. Für Authentifizierung — das Eingangstor deiner App — zählt das.
• Failover: Was passiert bei IdP-Ausfall? Fallback-Mechanismus? Multi-Region-Deploy?
• Vorfallhistorie: Checke das tatsächliche Statuspage-Archiv. Versprochene SLAs ≠ Realität.

Datenportabilität#

• Nutzer-Export: Kannst du alle Daten, incl. Metadaten, Org-Zugehörigkeiten und Rollen, exportieren? In welchem Format?
• Standardkonformität: Werden Standard-Protokolle (OIDC, SCIM) unterstützt, um künftige Migrationen einfach zu halten?
• Keine Lock-In-Signale: Proprietäre APIs, eigene Protokolle, abweichende Token-Formate — alles Lock-In-Indikatoren. Je proprietärer, desto schlimmer der Ausstieg.

Die Bewertungsmatrix: Ein praxisnahes Scoring-Framework#

Nach Bewertung aller Dimensionen brauchst du eine Vergleichsmethode. Hier das Priorisierungsframework:

P1 — K.O.-Kriterien (Pflicht oder raus)#

P2 — Stark bevorzugt (fehlt, kostet viel Engineering)#

P3 — Wichtig (binnen 12 Monaten nötig)#

P4 — Nice to have (kein Blocker)#

Wie nutzt du das: Beginne mit P1. Fällt ein Anbieter dort raus, direkt stoppen. Dann P2 und P3 scoren. Die beste P2+P3-Gesamtwertung gewinnt.

Verbreitete Evaluierungsfehler#

Wir sehen immer die gleichen Fallen. So umgehst du sie:

Fehler 1: Features statt Architektur bewerten#

Eine Feature-Liste sagt, was es gibt — aber nicht, wie es gebaut ist. Ein IdP kann "Organisationen" unterstützen, indem er Org-IDs im User-Metadata speichert. Das reicht im Baukasten-Test, macht aber Produktionsprobleme.

Lösung: Zu jedem Feature fragen: "Wie ist es gebaut?" — nicht: "Gibt's das?"

Fehler 2: Migration erst nach Auswahl beachten#

Teams wählen den "besten" IdP, starten Implementierung und merken dann, dass sie Nutzer nur per Zwangs-Reset übertragen können. Nun stehen sie vor mieser Migration oder starten wieder bei null.

Lösung: Migration direkt als erstes Filterkriterium.

Fehler 3: Demo zu stark gewichten#

Jede Anbieter-Demo glänzt. Sie zeigt nur den Idealweg mit leerer Datenbank und null Edge Cases. Dein Live-System hat gemergte Accounts, verrückte Unicode-Felder und Sessions, die es laut Theorie gar nicht geben müsste.

Lösung: Proof-of-Concept mit echten Daten verlangen. 1.000 echte Nutzer importieren, Auth-Flows testen.

Fehler 4: Die falschen Leute evaluieren lassen#

Nur das Platform-Team? Wählt, was technisch schick ist. Nur Produkt? Wählt leichteste Integration. Nur Security? Geht nach Compliance-Checkboxes.

Lösung: Evaluationsteam = Platform Engineering + Produkt + Security. Jeder hat eigene P1/P2-Interessen.

Fehler 5: Man vergisst, dass man irgendwann raus will#

Vendor-Lock-In ist real. Eigene SDKs, APIs außerhalb von Standards, Sonderformate — das erschwert jede Migration.

Lösung: IdPs nach Standardunterstützung (OIDC, OAuth2, SCIM) bevorzugen. Dein Zukunfts-Ich wird dankbar sein.

FAQ#

Wie lange dauert eine IdP-Evaluierung typischerweise?#

Für eine gründliche Evaluierung inkl. PoC solltest du mit 4-8 Wochen rechnen. Wer hetzt, begeht die genannten Fehler — vor allem bei der Migration. Rechne mit 2 Wochen für die Anforderungsaufnahme, 2-3 Wochen für Anbietervergleich & PoC, 1-2 Wochen für Stakeholder-Abstimmung.

Sollten wir Auth selbst bauen?#

Kommt auf die Phase an. Bis rund 10.000 Nutzer und ohne Unternehmenskunden reicht evtl. ein leichtgewichtiges Auth-Toolkit. Sobald SSO, Multi-Tenancy, MFA, Compliance-Doku dazukommen, kostet Wartung selbstgebauter Auth-Stacks sehr schnell mehr, als ein IdP kostet. Engineering-Teams investieren leicht 2-3 FTE in custom Auth — das sind $300-500K Jahr für Jahr als Opportunitätskosten.

Was ist der Unterschied zwischen CIAM und Workforce IAM?#

Customer Identity and Access Management (CIAM) ist, was Nutzer deiner App erleben — Registrierung, Login, Profile. Workforce IAM ist, was Mitarbeiter für interne Tools nutzen (z. B. Okta für Slack/Mails), hat andere Anforderungen. Dieser Guide behandelt CIAM.

Wie wichtig ist Open Source vs. proprietär?#

Open Source IdPs bieten Transparenz (Code-Review möglich), Portabilität (Self-Hosting) und Community-Input. Proprietäre IdPs punkten oft mit polierter UI & Managed Service. Die Kernfrage ist nicht "offen vs. geschlossen", sondern "kann ich im Zweifel weg?" Open Source macht das durch offene Datenmodelle und APIs leichter.

Wann sollte KI-Agentenauth P1 statt P3 sein?#

Wenn du schon KI-Features baust (Copilots, automatisierte KI-Workflows etc.), dann sofort nach P1 schieben. Ist KI in 6-12 Monaten auf der Roadmap, bleibt es P3, aber gewichte stark. Ist KI noch gar kein Thema, bleibt es P4 — in 6 Monaten erneut bewerten.

Wie evaluieren wir Preise, wenn Anbieter verschiedene Modelle haben?#

Fast alle IdPs rechnen nach Monthly Active Users (MAU) ab. Doch was als "MAU" gilt, variiert — z. B. jeder Login vs. jede Person, M2M-Tokens oft extra. Lass dir ein Angebot auf deine Zahlen machen: X Nutzer, Y Organisationen, Z M2M-Verbindungen, erwartetes Auth-Volumen. Immer Gesamtkosten, nicht Stückpreis, vergleichen.

Das Fazit#

Die Auswahl deines Identity Providers ist eine Infrastrukturentscheidung, kein Feature-Pick. Du entscheidest, wer jeden Nutzer zur Tür hereinlässt, wie jede API-Entscheidung getroffen und wie jede Audit-Spur für Compliance hinterlegt wird.

Das Framework oben deckt ab, was wirklich zählt — nicht nur Marketing-Buzzwords. Nimm es zum schnellen Filtern (P1-Kriterien zuerst), testet Kandidaten tief (P2/P3 und PoC), und triff eine Wahl, die Jahre hält, nicht Monate.

Teams, die das richtig machen, verbindet immer eines: Sie behandeln Identität als Infrastruktur, nicht als einmaliges Feature.