Schluss mit der gemieteten Login-Box: Das CTO-Playbook für selbstverwaltetes OAuth und Passkeys

Sie zahlen Miete für die Eingangstür Ihres Produkts. Diese Miete steigt schleichend. Der Vermieter wechselt das Schloss. Und wenn das Gebäude dunkel wird, gehen auch bei Ihnen die Lichter aus. Da Cloudflare die Optionen für selbstverwaltetes OAuth ausbaut und Passkeys inzwischen auf nahezu jedem Gerät, das Ihre Kunden nutzen, nativ verfügbar sind, ist 2026 das erste sinnvolle Zeitfenster, um die Kontrolle über Ihre Identitätsschicht zurückzuholen—ohne PagerDuty zu alarmieren.

Warum jetzt: drei Zwangsfaktoren, die Sie nicht ignorieren können

• Anbietervolatilität und Lock‑in sind real. CIAM‑Preise steigen, Enterprise‑Features werden zunehmend hinter Paywalls versteckt, und Ausfälle passieren weiterhin. Wenn Ihre Login‑Box ein Third‑Party‑Widget ist, gehören Ihnen weder die Verfügbarkeit noch die Roadmap. Sie brauchen eine IdP‑Exit‑Strategie.
• Cloudflare hat die Aktivierungsenergie gesenkt. Mit der jüngsten Ankündigung, selbstverwaltetes OAuth/OIDC mehr Teams zugänglich zu machen, dient die Edge nun auch als Identity‑Kontrollpunkt. Ob Sie OAuth an der Edge terminieren oder an Ihren eigenen IdP weiterleiten—das operative Gerüst ist einfacher geworden.
• Passkeys sind endlich Mainstream. Plattform‑Authentikatoren sind breit verfügbar auf iOS, Android, macOS und Windows. FIDO/WebAuthn‑Support deckt inzwischen die große Mehrheit moderner Browser und Geräte ab. Das bedeutet weniger Support‑Tickets und weniger kompromittierte Konten—wenn Sie es tatsächlich ausliefern.

Anders gesagt: Die Technologielücke, die das Auslagern von Identity für die meisten B2B/B2C‑Produkte gerechtfertigt hat, hat sich verringert. Das Geschäftsrisiko, die strategischste Oberfläche Ihres Stacks weiterhin zu mieten, ist gewachsen.

Sollten Sie 2026 OAuth insourcen? Ein Entscheidungsrahmen

Identity zu insourcen ist kein Dogma. Nutzen Sie diesen Filter für Ihre Entscheidung.

Grünes Licht (Insourcing dringend erwägen), wenn Sie Folgendes haben:

• Consumer‑ oder SMB‑B2B‑Skalenbetrieb (≥ 200k MAU), bei dem Preismodelle pro aktivem Nutzer oder Feature‑Gating die Unit Economics belasten.
• Multi‑Tenant‑SaaS mit Bring‑Your‑Own‑IdP (OIDC/SAML) und fein granularen Autorisierungsanforderungen. Sie wollen First‑Party‑Kontrolle über Scopes, Claims und Token‑Laufzeiten.
• Sicherheitsanforderungen jenseits der Vendor‑Defaults (DPoP, PAR, Refresh‑Token‑Rotation, Step‑Up‑Auth). Wenn Sie reguliert sind, tragen Sie die Verantwortung ohnehin irgendwann selbst.
• In‑house‑Fähigkeit, 0,5–1,0 FTE Senior Engineer für den Betrieb des IdP sowie 0,25–0,5 FTE SRE für HA/DR nach Go‑Live bereitzustellen. Das ist der ehrliche Dauerzustand.

Gelbes Licht (Hybrid empfohlen), wenn Sie Folgendes haben:

• Enterprise‑SSO‑Anforderungen über Dutzende Kunden‑IdPs (Okta, Entra, Ping), aber moderaten Self‑Serve‑Traffic. Behalten Sie einen Vendor als SAML‑Broker; besitzen Sie die Customer‑Auth für Self‑Serve und Tokens selbst.
• Stark mobilelastige Clients, bei denen sich SDKs nicht in einem Rutsch migrieren lassen. Nutzen Sie einen Edge‑Proxy für eine schrittweise Umstellung.

Rotes Licht (kaufen und weitermachen), wenn Sie Folgendes haben:

• Komplexe Zertifizierungen (FedRAMP High, PCI L1 als Händler, regionale Datenresidenz je Mandant) ohne Bereitschaft, HSMs/KMS pro Region zu betreiben.
• Keine Bandbreite, um einen sicheren HA‑Datenspeicher für Identity zu betreiben (Multi‑Region Postgres oder CockroachDB + KMS + Secrets‑Rotation). Identity ist entweder langweilig oder brennt. Dazwischen gibt es nichts.

Architekturoptionen, die Ihre Roadmap nicht sprengen

Option A: An der Edge terminiertes OAuth mit selbstverwaltetem Core

Verwenden Sie die Edge (z. B. Cloudflare) als Policy‑ und Session‑Boundary. Die Edge:

• Übernimmt OAuth/OIDC‑Redirects, Bot‑Abwehr, Geo-/Risikobewertung und Gerätesignale.
• Injiziert verifizierte Identity‑Header oder ein signiertes Session‑Token in Ihre App.
• Leitet Token‑Ausstellung/-Validierung im Hintergrund an Ihren IdP (Keycloak, ZITADEL, ORY) weiter.

Warum das funktioniert: Sie halten den App‑Code simpel (Header oder ein signiertes Cookie prüfen), gewinnen Latenzvorteile (Token‑Checks an der Edge) und können den Core‑IdP später austauschen, ohne App‑Verträge zu ändern.

Option B: Open‑Source‑IdP als Source of Truth

Betreiben Sie einen modernen, von Ihnen kontrollierten IdP:

• Keycloak für bewährtes OIDC/SAML, Admin‑UI und SCIM. Schwergewichtig, aber funktionsreich.
• ZITADEL für mandantenfähiges, audit‑freundliches CIAM mit guter Developer‑Experience.
• ORY Hydra/Kratos für komponierbare Flows, wenn Sie die UX eng selbst besitzen wollen.
• Authentik für kleinere Teams und einfachere Setups.

Stellen Sie ihn mit mTLS hinter Ihre Edge. Nutzen Sie verwaltetes Postgres mit regionsübergreifenden Read‑Replikas. Speichern Sie Signierschlüssel in einem Cloud‑KMS. Veröffentlichen Sie JWKS unter einer stabilen URL.

Option C: Hybrid (Workforce‑SSO behalten, Customer Identity selbst besitzen)

Für B2B‑SaaS mit Enterprise‑Kunden: Behalten Sie Ihr Workforce‑SSO bei einem Vendor. Das Insourcen der Workforce‑Identity rechnet sich selten. Aber besitzen Sie Ihre Kunden‑Identity—Tokens, Scopes und Passkeys—, wo Unit Economics und UX zählen.

Wie „gut“ 2026 aussieht: ein Referenzdesign

Protokolle und Flows

• OIDC mit PKCE für alle öffentlichen Clients (Mobile, SPAs). Niemals den Implicit Flow shippen. Siehe RFC 7636.
• DPoP, um Tokens an den Schlüssel des Clients zu binden und Bearer‑Diebstahl zu reduzieren. Siehe RFC 9449. Reif genug für Pilotierungen bei risikoreichen APIs.
• Pushed Authorization Requests (PAR), um Request‑Parameter vom Front‑Channel fernzuhalten und gegen Mix‑up und Manipulation zu härten. Siehe RFC 9126.
• Kurzlebige Access Tokens (5–10 Min.) mit rotierenden Refresh‑Tokens. Bei Wiederverwendung widerrufen.
• Back‑Channel‑Logout für Server‑Side‑Apps; Front‑Channel für SPAs als Best‑Effort. Planen Sie Ihre Cache‑Invalidierung.

Passkeys und MFA

• WebAuthn‑Passkeys zuerst, Passwörter optional. Verwenden Sie auffindbare Anmeldedaten und erzwingen Sie User‑Verifizierung. Siehe WebAuthn L3.
• TOTP als einziger Fallback. SMS abschaffen. E‑Mail‑Magic‑Links nur für die Kontowiederherstellung mit kurzen TTLs (≤10 Minuten) und Gerätebindung beibehalten.
• Progressive Registrierung: Fordern Sie Nutzer mit hoher Intent während Erfolgserlebnissen (post‑login, post‑purchase) auf, nicht willkürlich beim Sign‑in.
• Step‑Up für riskante Aktionen (Auszahlungen, Key‑Rotation, RBAC‑Änderungen), die eine aktuelle WebAuthn‑Assertion erfordern.

Mandantenfähigkeit und Claims

• Mandantenspezifische OAuth‑Clients mit isolierten Redirect‑URIs und Scopes. Vermeiden Sie globale Clients für B2B‑SaaS.
• Namespaced Claims in ID‑Tokens (z. B. https://yourco.com/roles, https://yourco.com/tenant). Halten Sie Access Tokens auf eine Audience beschränkt.
• SCIM + JIT‑Provisionierung für Enterprise‑Mandanten, aber hinter Enterprise‑Plänen absichern, um den Blast‑Radius klein zu halten.

Betrieb und Sicherheit

• HA/DR: Multi‑AZ‑Primary, regionsübergreifendes Failover vierteljährlich testen. Schlüssel im KMS mit Regionsreplikas. Signierschlüssel alle 90 Tage rotieren; alte Schlüssel 7 Tage als Schonfrist im JWKS belassen.
• Observability: Auth‑Events als strukturiertes JSON an Ihr SIEM ausgeben. Verfolgen Sie Login‑Erfolgsrate, mediane End‑to‑End‑Auth‑Latenz, Passkey‑Registrierungsquote, Refresh‑Token‑Wiederverwendungsrate und SSO‑Einrichtungszeit pro Mandant.
• Test‑Harness: eine Headless‑Browser‑Suite, die gängige Flows (Login, Accounts verknüpfen, Passkey registrieren, Session widerrufen) bei jedem Deploy gegen Staging ausführt.

Ein pragmatischer Migrationsplan, der Nutzer nicht aussperrt

1) Inventarisieren und den Blast‑Radius modellieren

• Jeden OAuth/OIDC‑Client auflisten: App‑Name, Typ (SPA/Native/Web), Redirect‑URIs, Scopes, Audiences, SDK‑Versionen, Token‑Speichermuster.
• Identitätsdaten abbilden: Was steht in Nutzerprofilen, wo liegt es, wer schreibt darauf (Marketing vs. Produkt vs. Support) und was Sie backfillen müssen.
• Baseline‑KPIs: tägliche Login‑Versuche, Erfolgsrate, durchschnittliche End‑to‑End‑Auth‑Zeit, Volumen an Passwort‑Resets, Account‑Übernahmen (ATO), SSO‑Time‑to‑Live.

2) Neuen IdP parallel aufsetzen

• Den gewählten IdP hinter der Edge mit einer neuen, versionierten Issuer‑URL bereitstellen (z. B. https://id-v2.yourco.com).
• Wesentliche Verbindungen spiegeln (E‑Mail, SMS, falls noch für Recovery benötigt, WebAuthn, SCIM). Eine kleine Gruppe von Pilot‑Mandanten und Ihre eigenen Workforce‑Accounts seeden.
• Account Linking implementieren: Wenn sich derselbe Nutzer über den alten IdP anmeldet, ein First‑Party‑Token ausstellen und die Identität im neuen IdP still anlegen/verknüpfen. So können Sie im Dual‑Run fahren.

3) Passkeys als „Upgrade“ ausliefern, nicht als Verpflichtung

• Per Feature Flags steuern. Starten Sie mit 5–10% Traffic dort, wo die Geräteunterstützung am höchsten ist (Chrome/Safari aktuell auf Desktop/Mobile).
• Bieten Sie nach erfolgreichem Sign‑in eine Ein‑Klick‑Registrierung an. Blockieren Sie die Login‑Wall nicht mit einer Registrierungsaufforderung.
• Verfolgen Sie Registrierungsquote und Deltas der Login‑Zeit. Rechnen Sie damit, dass 20–40% der aktiven Nutzer innerhalb von 90 Tagen registrieren, wenn Sie zum richtigen Zeitpunkt fragen und den Nutzen erklären.

4) Strangler‑Cutover app‑weise

• Für serverseitig gerenderte Apps: Die Edge auf Validierung gegen den neuen Issuer umschalten, den alten IdP 1–2 Wochen als Fallback‑Pfad mit Logging beibehalten.
• Für SPAs und Mobile: SDK‑Konfig‑Updates ausliefern, die auf den neuen Issuer zeigen und PKCE erzwingen. Während einer Schonfrist beide Tokenformate unterstützen, indem APIs in ihrer Validierungs‑Middleware beide Issuer akzeptieren.
• Redirect‑URIs je Client rotieren, dann den alten Client im Vendor‑IdP widerrufen, wenn das Log‑Volumen unter 1% der Baseline fällt.

Die Zahlen: Wo der ROI tatsächlich sichtbar wird

• Latenz: Auth‑Checks an der Edge zu terminieren spart typischerweise 100–200 ms gegenüber Round‑Trips zu einem einzigen US‑Region‑IdP für globale Nutzer. Das hebt die Conversion messbar bei Login‑ und Checkout‑Flows.
• Support‑Last: Mit Passkeys sinken „Kann mich nicht anmelden“‑Tickets deutlich. Teams berichten nach breiter Passkey‑Einführung von 20–50% weniger Passwort‑Reset‑Anfragen. Ihr genaues Delta hängt von Ihrer Zielgruppe und davon ab, wie aggressiv Sie Passwörter entfernen.
• Fraud und Account‑Übernahmen: Passkeys plus DPoP reduzieren Credential‑Stuffing und Bearer‑Token‑Replay spürbar. Schon eine kleine Reduktion von ATOs bezahlt die Migration zurück.
• Enterprise‑Velocity: Mandantenspezifische Clients und Namespaced Claims verkürzen SSO‑Onboarding von Wochen auf Tage. Wenn Sie pro Quartal einen zusätzlichen Enterprise‑Deal schließen, hat sich das Projekt amortisiert.

Risiken und wie Sie sie eindämmen

• Aussperrungen (Lockouts): das existenzielle Risiko. Führen Sie Dark Launches mit gespiegelt em Traffic und simulierten Ausfällen durch. Halten Sie ein Runbook bereit, um DPoP/PAR pro Client zu deaktivieren, falls SDKs sich falsch verhalten.
• Schlüsselmanagement: Schlüsselverlust ist Geschäftsverlust. Signierschlüssel im Cloud‑KMS mit Dual Control (Vier‑Augen‑Prinzip) speichern, Backups anlegen und die Notfallrotation dokumentieren. JWKS mit cache‑gesteuerten TTLs veröffentlichen.
• Fallback‑Wildwuchs: Jeder Fallback ist ein zukünftiger Vorfall. Genau einen Fallback (TOTP) beibehalten. E‑Mail‑Magic‑Links nur als Recovery behandeln.
• Regulatorische Angriffsfläche: Insourcing bedeutet, dass Sie für mehr Felder Auftragsverarbeiter und Verantwortlicher sind. Profilfelder minimieren, Daten‑TTLs setzen und Zugriffe protokollieren. Wenn Sie Datenresidenz zusagen, verifizieren Sie, dass Platzierung und Backups Ihres IdP‑Datastores dies durchsetzen.

Build vs. Buy: eine nüchterne TCO‑Gegenüberstellung

Nehmen wir ein B2B‑SaaS im Growth‑Stadium mit 300k MAU und Enterprise‑SSO an.

• Buy (Status quo): planbare Integration, schnelle SSO‑Erfolge, aber steigende Kosten pro MAU/Feature und begrenzte Kontrolle über Tokens, Claims und UX. Sie tragen das Risiko von Vendor‑Ausfällen und Lock‑in.
• Self‑managed: Rechnen Sie mit 0,5–1,0 FTE Senior Engineer, der den IdP verantwortet, plus 0,25–0,5 FTE SRE für HA/DR. Infra: zwei mittelgroße Postgres‑Instanzen über Regionen, Edge‑Worker, Metriken/Alerts. Nach der Stabilisierung fließt die Velocity in Features, die Sie wollen (Passkeys, Step‑Up, DPoP) statt in das Warten auf eine Roadmap.

Wir haben Teams gesehen, die innerhalb von 9–15 Monaten den Break‑even erreichen, wenn bereits Edge‑Infrastruktur vorhanden ist—und schneller, wenn die Unit Economics empfindlich auf Gebühren pro aktivem Nutzer reagieren. Ist Ihr Login konversionskritisch (Consumer‑Media, Fintech‑Onboarding), können die UX‑ und Latenzgewinne die Umstellung allein rechtfertigen.

Was Sie Ihrem Team am Montag mitgeben

1. Haltung wählen: Für die meisten B2B‑SaaS Edge‑terminiert + selbstverwalteter Core (A) oder Hybrid (C). Vermeiden Sie Spezial‑Flows; bleiben Sie bei OIDC + PKCE.
2. IdP wählen: ZITADEL für mandantenfähiges CIAM, Keycloak für Funktionsbreite, ORY bei Bedarf an Komponierbarkeit. Entscheiden Sie diese Woche; hinter der Edge können Sie später tauschen.
3. Token‑Policy definieren: 5–10 Min. Access Tokens, rotierende Refresh‑Tokens, Audience‑Scoping, Namespaced Claims, DPoP für risikoreiche APIs, PAR für alle Confidential Clients.
4. Staging aufsetzen: IdP + Edge + Postgres‑HA + KMS. JWKS veröffentlichen. Logs an Ihr SIEM anbinden. Eine Headless‑Auth‑Test‑Suite bauen.
5. Passkeys hinzufügen: WebAuthn mit auffindbaren Anmeldedaten und strikter User‑Verifizierung implementieren. TOTP als Fallback beibehalten. Progressive Registrierungs‑UX planen.
6. Eine Account‑Linking‑Bridge ausliefern: Alte IdP‑Tokens akzeptieren, First‑Party‑Sessions ausstellen, verknüpfte Identitäten im Hintergrund im neuen IdP anlegen.
7. Pilot mit internen Accounts und 1–2 freundlichen Mandanten: Login‑Latenz, Erfolgsrate und Registrierung messen. Die Kleinigkeiten beseitigen.
8. Zuerst Low‑Risk‑Apps umschalten: Server‑gerenderte Admin‑UI, dann SPA, dann Mobile. Auf API‑Ebene zwei Wochen Dual‑Issuer‑Schonfrist beibehalten.
9. Fallbacks gezielt abschaffen: Passwörter für Kohorten entfernen, die Passkeys registriert haben. Step‑Up bei sensiblen Flows erzwingen.
10. Das Runbook schreiben: Key‑Rotation, Notfall‑Rollback, Tenant‑Cutover‑Checkliste und ein On‑Call‑Skript für weit verbreitete Login‑Fehler.

„Und was ist mit Social Logins und Enterprise‑SSO?“

Behalten Sie sie. Ihr IdP sollte als Broker für OIDC/SAML/Social‑Provider agieren. Im B2C ist Social ein Convenience‑Pfad, um Nutzer durch die Tür zu bekommen; konvertieren Sie sie am ersten Tag nach dem Login auf Passkeys. Im B2B bleibt Enterprise‑SSO, aber machen Sie die Verbindung jedes Mandanten zu einem First‑Class‑Client mit isolierten Redirect‑URIs und Scopes, damit eine Fehlkonfiguration eines Mandanten nicht die Nutzer eines anderen blockiert.

Nearshore‑Leverage: Wie Sie umsetzen, ohne das Kernprodukt auszubremsen

Hier verdient ein erfahrenes Nearshore‑Pod sein Geld. Geben Sie einem in Brazil ansässigen Plattform‑Team ein klares Mandat: die Edge härten, den IdP aufsetzen, Passkeys integrieren und das Migrations‑Harness ohne App‑Rewrites liefern. Ihre Core‑Product‑Squads bleiben für Roadmap‑Features reserviert. Mit 6–8 Stunden Überschneidung und niedrigerer TCO bekommen Sie einen IdP, den Sie besitzen—ohne ein Quartal Feature‑Freeze.

Wo Sie anfangen zu lesen (und was Sie kopieren, nicht erfinden)

• Die Ankündigung von Cloudflare, selbstverwaltetes OAuth/OIDC mehr Teams zugänglich zu machen, ist ein Wegweiser: Die Edge ist Ihre neue Identity‑Grenze. Nutzen Sie sie.
• Specs kopieren, nicht neu interpretieren: PKCE, PAR, DPoP und WebAuthn.
• Einen IdP auswählen und ausliefern. Keycloak und ZITADEL haben beide vernünftige Defaults für OIDC, Passkeys und Mandantenfähigkeit.

Das Fazit

Die Identitätsschicht ist eine Produktschnittstelle, die Sie besitzen sollten. 2026 sind Tooling, Browser‑Support und Edge‑Primitiven endlich gut genug, dass Sie es können. Wenn Sie Ihre Login‑Box noch mieten, bauen Sie jetzt eine Ausfahrt—bevor Preisänderungen oder ein Ausfall Sie dazu zwingen.

Wesentliche Erkenntnisse

• Selbstverwaltetes OAuth ist jetzt praktikabel: Nutzen Sie die Edge als Identity‑Boundary und halten Sie Apps einfach.
• Passkeys als Standard ausliefern; genau einen Fallback (TOTP) beibehalten. Rechnen Sie mit weniger Resets und weniger ATOs.
• PKCE, PAR und DPoP einführen. Kurzlebige Access Tokens mit rotierenden Refresh‑Tokens sind Pflicht.
• Per App im Strangler‑Modell migrieren, Issuer dual betreiben und loggen, und Flows End‑to‑End mit Headless‑Browsern testen.
• Customer Identity (CIAM) selbst besitzen; Workforce‑SSO beim Vendor belassen, sofern es keinen starken Gegen‑Grund gibt.
• Nearshore‑Pods können IdP und Edge‑Integration liefern, ohne die Core‑Product‑Teams einzufrieren.