Identität · OpenID Connect

Single Sign-On, eingebaut.

CodeB bringt einen eigenen OpenID-Connect-Identity-Provider mit. Anmelden geht auf jeder Seite: Ein Button auf dem Landingformular gibt Teilnehmern ein Verifiziert-im-Anruf-Badge, derselbe Button im Webphone-PWA registriert ihre SIP-Identität automatisch, und Admin- sowie Drittanwendungen (Nextcloud, eigene RPs) föderieren alle gegen dieselbe Benutzerdatenbank pro Mandant. Cookie-frei, PKCE-only-Public-Clients oder confidential Clients mit Secret — suchen Sie sich aus, was passt.

OIDC ist standardmäßig aktiv. Discovery-URL: https://<ihr-host>/.well-known/openid-configuration

In die eigene Seite einbauen? → Integrations-Anleitung lesen · Datenfluss ansehen

Plattform-Integrationen
Nextcloud user_oidc · Social Login WordPress OpenID Connect Generic

Was Sie bekommen

EU-Wallet-Anmeldung LIVE

Das OID4VP-1.0-Verifier-Substrat ist ausgerollt. Jede spezifikationskonforme EU Digital Identity Wallet (EUDI-Wallet) kann sich bei einem CodeB-Mandanten anmelden, registrieren oder abonnieren. ES256-signierte Authorization-Requests, DCQL-Queries, JWE-verschlüsselte Responses, SD-JWT VC mit selektiver Offenlegung — ausgespielt über das OIDC-userinfo, das Ihre Relying Parties bereits konsumieren.

Funktionsübersicht · Selbst testen · Funktionsnachweis · API-Doku · Kostenlose Schulung (1844)

OID4VP 1.0 · eIDAS 2.0

Drei Methoden, ein Bildschirm

Passwort, Passkey (FIDO2 / WebAuthn) und EU-Wallet-(EUDI-)Anmeldung stehen gleichberechtigt nebeneinander auf /login.html — gleiches Gewicht, keine Hierarchie, keine dritte URL zum Merken. Magic-Link-Anmeldung per E-Mail ist einen Klick darunter. Relying Parties können mit ?method=passkey / ?method=eu-wallet / ?method=password direkt auf eine Methode deeplinken, damit Nextcloud, WordPress und andere OIDC-Clients Nutzer direkt in den richtigen Flow leiten.

Picker ausprobieren · Passkey-Flow · EU-Wallet-Flow

UX · ein Credential-Store

Standardbasiert

OpenID Connect Core 1.0, Authorization-Code-Flow mit PKCE (S256), RS256-signierte JWTs. Discovery nach RFC 8414, JWKS nach RFC 7517. Jeder RP, der OIDC spricht, funktioniert.

OIDC Core 1.0

Cookie-frei, ehrlich

Keine Cookies, nirgends — weder Session noch Tracking. Sign-in über mehrere RPs nutzt eine signierte, 30-minütige Same-Origin-Assertion in localStorage am IdP-Ursprung: wird nie an andere Sites gesendet, nie für Cross-Site-Tracking benutzt, beim Logout gelöscht. Access- und Refresh-Tokens pro Tab leben in sessionStorage und verschwinden, wenn der Tab schließt. Vollständige Architektur auf der Datenfluss-Seite.

Datenschutz

Ein Credential-Store

Sign-in nutzt denselben HA1-Passwort-Hash, den auch Ihre SIP-Softphones verwenden. Kein Klartext-Passwort erreicht je den Server — der Browser hasht es vor dem Posten. Ein Benutzerdatensatz treibt Sprache und Identität.

Warum HA1: CodeB verwendet SIP-kompatible HA1-Digests, damit derselbe Benutzerdatensatz sowohl Softphones (Digest-Auth nach RFC 3261) als auch OIDC-Anmeldung abdeckt. HA1 wird als passwortäquivalentes Geheimnis behandelt. Eine moderne-KDF-Option (Argon2 / scrypt / PBKDF2-SHA256) für reine Web-/OIDC-Deployments ohne SIP-Softphones ist auf der Roadmap.

Keine doppelten Nutzer

Schlüssel pro Mandant

Jeder Mandant erhält seinen eigenen 2048-bit-RSA-Signaturschlüssel, der beim ersten Bedarf erzeugt und unter App_Data/<tenant>/oidc/ persistiert wird. Tokens für Mandant A verifizieren niemals gegen Mandant B.

Multi-Mandant

Rollen, nicht nur Identitäten

Vier Rollen out-of-the-box: admin, user, siponly, guest. Die Rolle reist im JWT als eigenem Claim und als Standard-groups-Eintrag. Eigene Custom-Groups pro Nutzer setzen Sie in der Admin-UI und steuern damit direkt die Nextcloud-/RP-Mitgliedschaft im Token. Admin-Seiten erzwingen role === "admin" serverseitig bei jedem Request.

RBAC

Verifiziert-im-Anruf-Badge

Melden Sie sich auf der Landingpage vor dem Beitritt an, und Ihre Konferenzkachel zeigt jedem Teilnehmer das bernsteinfarbene CodeB-Schild. Anti-Impersonation gratis, kein externer Identity-Provider, keine Zoom-artige Verified-Name-Erweiterung nötig.

Anti-Impersonation

Passwortloser E-Mail-Link-Login

Nutzer, die kein Passwort tippen wollen (oder es am fremden Telefon vergessen haben), wählen „Anmeldelink per E-Mail senden“ im Login-Formular, geben ihre E-Mail-Adresse ein, und ein Einmal-Link landet im Posteingang. Anklicken — angemeldet. Single‑use, 15 Minuten Gültigkeit, keine Enumeration. AMR ["user"] und ACR urn:codeb:acr:email-link markieren das Verfahren als schwächer als Passwort, sodass RPs für sensible Operationen Step‑up verlangen können.

Passwortlos

Ein Passkey, alle Anwendungen

Einmaliges FIDO2-Credential (TouchID/FaceID/Windows Hello/Hardware-Token) am CodeB-IdP registrieren. Ab dann erhält jeder Relying Party — Nextcloud, WordPress, GitLab, Ihr CRM, eigene Anwendungen — phishing‑resistente Authentifizierung umsonst, denn alle sprechen den OIDC-Standard mit Ihrem CodeB-Host. Der RP fasst den Passkey nie an, sieht das Credential nicht und muss WebAuthn nicht implementieren. Er konsumiert ein signiertes ID-Token mit amr: ["hwk","user"] und acr: urn:codeb:acr:hwk-mfa — fertig.

Skaleneffekt:

  • Ein Credential zu verwalten — ein Widerruf bei Laptop-Verlust meldet den Nutzer per RP-Initiated Logout aus jeder angeschlossenen App ab.
  • Jeder RP kann Step-up via acr-Claim verlangen — sensible Aktionen brauchen Passkey, normale akzeptieren Passwort.
  • Neue App im Stack: null Auth-Aufwand, sie erbt die bestehende Faktor-Matrix.
  • Werden zusätzlich EU-Wallet-verifizierte Claims am IdP gespeichert, fließen sie mit — der RP sieht given_name, family_name, birthdate aus staatlich verankerter Quelle ohne wallet-spezifischen Code.
Federations-Gewinn

Authenticator-App (TOTP)

Nutzer, die keinen Passkey hinterlegen wollen, können die Passwort-Anmeldung trotzdem mit einem standardkonformen Time-Based One-Time Password (TOTP, RFC 6238) absichern. QR-Code in /account.html scannen mit einer beliebigen Authenticator-App — Google Authenticator, Microsoft Authenticator, 1Password, Bitwarden, Authy — und das Login-Formular fragt nach dem Passwort einen 6-stelligen Code ab.

8 Einmal-Recovery-Codes werden bei der Aktivierung erzeugt — für den „Handy in der Waschmaschine“-Fall. Ein E-Mail-Fallback kann einen kurzlebigen 6-stelligen Code an die hinterlegte Adresse schicken. Das Shared Secret liegt verschlüsselt in App_Data/<tenant>/users/<u>/totp.json, niemals auf einem Anbieter-Server. Aktivieren, verifizieren und deaktivieren werden in dasselbe OIDC-Audit-Log geschrieben wie alles andere. Passkey- und EU-Wallet-Anmeldungen überspringen den TOTP-Schritt — sie sind bereits eigenständige starke Faktoren.

Für den „alles weg“-Fall — Authenticator weg, Recovery-Codes weg, E-Mail unerreichbar — kann ein Admin im /register.html-Benutzerdialog mit einem Klick die TOTP-Aktivierung zurücksetzen. Der Override ist audit-geloggt mit Admin und Ziel-Nutzer. Brute-Force-Schutz: jeder Fehlversuch erhöht einen Sitzungs-Zähler, nach 5 falschen Codes wird die Sitzung vernichtet — der Angreifer muss einen neuen Passwort+TOTP-Ablauf starten, nicht einfach weiter raten.

RFC 6238 · AMR otp

Authentifizierungs­faktor im Token

Jedes id_token und access_token führt amr (RFC 8176) und acr mit. RPs sehen den tatsächlichen Faktor — ["pwd"] für Passwort, ["hwk","user"] für FIDO2-Passkey — und können Step-up-Authentifizierung dort verlangen, wo es zählt.

RFC 8176

Hot-Key-Rotation

Zwei Signaturschlüssel können gleichzeitig aktiv sein. Benennen Sie private-key.xml in private-key-previous.xml um; der nächste Request erzeugt einen neuen aktiven Schlüssel. JWKS veröffentlicht beide, der kid in jedem Token verankert ihn auf den richtigen. Kein IIS-Recycle, keine verlorenen Sessions.

Zero-Downtime

Token-Revocation (RFC 7009)

POSTen Sie ein Refresh-Token an /oidc.ashx?action=revoke, um eine Sitzung sofort IdP-seitig zu beenden. Confidential Clients authentifizieren sich mit Secret; Public Clients widerrufen ohne Auth. Liefert immer 200, damit kein Token-Gültigkeits-Enumeration möglich ist.

Betrieb

Integrations-Anleitung

CodeB-Anmeldung in die eigene App einbauen ist ein Config-Block. Das OIDC-How-To führt durch Discovery, PKCE, Token-Validierung und Refresh mit Copy-Paste-Beispielen in Vanilla-JS und Node/Express.

Entwickler

Die Endpunkte

Standard-OIDC-URLs. RPs brauchen typischerweise nur die Discovery-URL — alles andere wird automatisch entdeckt.

EndpunktZweck
/.well-known/openid-configuration Discovery-Dokument. RFC 8414. Listet jeden anderen Endpunkt und die unterstützten Algorithmen.
/.well-known/jwks.json JSON Web Key Set. RFC 7517. Der öffentliche RSA-Schlüssel des Mandanten, damit jeder RP Signaturen verifizieren kann.
/oidc.ashx?action=authorize Authorization-Endpunkt. Leitet zum Login-Formular und mit Auth-Code zurück zum RP.
/oidc.ashx?action=token Token-Endpunkt. Tauscht den Auth-Code (mit PKCE-Verifier) gegen Access-Token, ID-Token und Refresh-Token.
/oidc.ashx?action=userinfo UserInfo-Endpunkt. Liefert sub, role und Profil-Claims des angemeldeten Nutzers.
/oidc.ashx?action=end_session RP-initiierter Logout. Löscht Tokens clientseitig, leitet zur post_logout_redirect_uri.

RP in drei Zeilen verkabeln

Jeder OIDC-konforme Relying Party funktioniert. Auf die Discovery-URL zeigen, die öffentliche Client-ID codeb-admin verwenden — fertig.

Issuer https://phone.codeb.io Client ID codeb-admin Client-Typ public (PKCE-only, kein Secret) Redirect URI https://<ihr-rp>/oidc-callback Scope openid profile email PKCE-Methode S256

Das Discovery-Dokument liefert authorization_endpoint, token_endpoint, jwks_uri, id_token_signing_alg_values_supported und den Rest automatisch.

So sieht das ID-Token aus

RS256-signiertes JWT. Standard-OIDC-Claims plus eine mandantenscharfe role und jedes Profilfeld, das die Administration für diesen Nutzer hinterlegt hat.

{ "iss": "https://phone.codeb.io", "sub": "alice", "aud": "codeb-admin", "exp": 1748467200, "iat": 1748463600, "auth_time": 1748463600, "name": "Alice Walker", "preferred_username": "alice", "email": "alice@example.com", "email_verified": true, "role": "admin", "groups": ["admin"] }

Cookie-frei, by Design

OIDC-Implementierungen stützen sich typischerweise auf ein Session-Cookie am IdP, um den Nutzer über /authorize-Aufrufe hinweg „angemeldet“ zu halten. CodeB nicht. Das Login-Formular parst die ursprüngliche Authorize-URL, validiert PKCE-Challenge und Redirect-URI serverseitig, mintet den Auth-Code direkt und postet ihn als JSON zurück. Der Browser navigiert zur Callback-URL des RP, ohne je über einen cookietragenden Redirect zu laufen.

Das hält die Datenschutzhaltung ehrlich: keine Cookies, nirgends auf der CodeB-Seite, OIDC inklusive. Wer cookie-frei wirbt, bleibt cookie-frei.

EU-Digital-Identity-Wallet-Anmeldung

Die OIDC-Schicht von CodeB akzeptiert die EU Digital Identity Wallet (EUDI-Wallet) als gleichwertige Anmeldemethode. Das Verifier-Substrat — OID4VP 1.0 mit HAIP-1.0-client_id-Schema, DCQL-Credential-Queries, ECDH-ES + A128GCM JWE-verschlüsselte Responses, SD-JWT VC mit KB-JWT Holder-Binding — wurde am 08.06.2026 ausgerollt und läuft End-to-End gegen jede spezifikationskonforme Wallet.

Für Relying Parties ändert sich dabei nichts: Die verifizierten Credential-Claims werden über denselben /oidc.ashx-userinfo-Endpunkt und dasselbe ID-Token ausgespielt, das Ihre Anwendung bereits konsumiert. Eine Nutzeranmeldung via Passwort, Smartcard oder EU-Wallet sieht auf RP-Ebene identisch aus — der amr-Claim zeigt an, welcher Faktor verwendet wurde.

Ab Dezember 2027 ist jedes regulierte EU-Unternehmen der Privatwirtschaft — Banken, Telekommunikationsanbieter, Versicherungen, große Plattformen, Gesundheitswesen, öffentliche Auftragnehmer — gesetzlich verpflichtet, die EU-Wallet als Kundenanmeldung zu akzeptieren (eIDAS 2.0 Artikel 5f Abs. 2). CodeB-Mandanten haben den Verifier heute live; am Tag, an dem die Regel greift, steht der Stack bereit.

Volle Funktionsübersicht → · Live-Flow testen → · Verifizierter Funktionsnachweis → · Öffentliche Verifier-API →

Was noch NICHT erledigt ist — ehrlich: Die Issuer-Signaturkette gegen die EU List of Trusted Lists (LoTL) ist iter-2 und kommt, wenn das EUDI-Wallet-Ökosystem weiter reift. Heute validiert der Verifier das Protokoll, vertraut dem Issuer-Schlüssel aber out-of-band. Produktive hochsichernde Identitätsverifizierung sollte auf iter-2 plus eine notifizierte nationale Wallet warten. Die OpenID-Foundation-Selbstzertifizierung für OID4VP 1.0 + HAIP 1.0 ist in Arbeit.

Multi-Mandant von Tag eins

Mandantenidentität ist die Anfrage-Domain — wie im Rest von CodeB. Ein Nutzer, der sich auf phone.acme.com anmeldet, trifft den Acme-RSA-Schlüssel und die Acme-SIP-Credential-Datei; ein Nutzer auf phone.contoso.com trifft den Contoso-Schlüssel und die Contoso-Credentials. Die beiden Mandanten teilen keinen Zustand.

Einen neuen Mandanten anlegen heißt einen Hostnamen hinzufügen. Die erste Anfrage an /oidc.ashx erzeugt den RSA-Schlüssel des Mandanten und persistiert ihn unter App_Data/<tenant-domain>/oidc/private-key.xml. Keine Schemamigration, kein Restart, keine Downtime für die anderen Mandanten.

Betriebsnotizen

FrageAntwort
Wie werden Passwörter gespeichert? Als HA1-Digests: MD5(user:realm:password). Das Klartext-Passwort erreicht nie den Server — das Login-Formular hasht es im Browser. Dasselbe HA1, das Ihre SIP-Softphones bereits verwenden.
Wo liegen Benutzerkonten? App_Data/<tenant>/sip-credentials/<tenant-slug>.json. Verwalten Sie sie über die Register-Admin-Seite.
Wo liegt der private Schlüssel? App_Data/<tenant>/oidc/private-key.xml. Reines XML, nicht im Quellcode. Sichern Sie ihn mit dem Rest von App_Data.
Wie rotiere ich den Schlüssel? Datei löschen und IIS-App-Pool recyceln. Die nächste Anfrage erzeugt einen neuen Schlüssel mit neuer kid. RPs holen JWKS automatisch neu.
Gibt es ein Audit-Log? Ja — App_Data/<tenant>/logs/codeb-oidc-YYYY-MM-DD.log (JSONL), und ein paralleler Feed in das Windows Event Log unter Source CodeBOIDC.
Wie lange leben Tokens? Access-Tokens 1 Stunde. Refresh-Tokens 7 Tage. ID-Tokens 1 Stunde. Auth-Codes 60 Sekunden, einmalig.

Den Rest sehen? Alle Funktionen →