Was ist der OpenID-Connect-Identity-Provider von CodeB?

CodeB liefert einen self-hosted, normkonformen OpenID-Connect-Identity-Provider. Implementiert Authorization Code mit PKCE (S256), RS256-signierte JWTs, RSA-Schlüssel pro Mandant, RFC 8414 Discovery, RFC 7517 JWKS, RFC 7009 Token-Revocation und RFC 7662 Token-Introspection. Jede Relying Party, die OIDC spricht, funktioniert sofort.

Unterstützt CodeB EU-Wallet-Anmeldung?

Ja. Seit 08.06.2026 läuft ein live OID4VP-1.0-Verifier-Substrat. Jede spezifikationskonforme EU Digital Identity Wallet (EUDI-Wallet) kann sich bei einem CodeB-Mandanten anmelden, registrieren oder abonnieren. Die Pipeline läuft ES256-signierte Authorization-Requests, DCQL-Credential-Queries, JWE-verschlüsselte Responses, SD-JWT-VC mit selektiver Offenlegung und KB-JWT Holder-Binding, und liefert verifizierte Claims über den Standard-OIDC-userinfo-Endpunkt aus.

Ist CodeBs OIDC wirklich cookie-frei?

Ja. Keine Cookies — weder Session noch Tracking. Single Sign-On über mehrere Relying Parties nutzt eine signierte, 30 Minuten gültige, Same-Origin-Assertion im localStorage am IdP-Origin: niemals an andere Sites gesendet, niemals für Cross-Site-Tracking verwendet, beim Logout gelöscht. Per-Tab Access- und Refresh-Tokens liegen im sessionStorage und verschwinden mit dem Tab.

Welches OID4VP-Profil implementiert CodeB?

OID4VP 1.0 mit dem HAIP-1.0-client_id-Schema — ES256-signierte JAR-Authorization-Requests, x509_san_dns-client_id, DCQL-Credential-Queries, JWE-verschlüsselte Responses mit ECDH-ES + A128GCM, SD-JWT-VC mit KB-JWT Holder-Binding.

Ist CodeB EUDI-zertifiziert?

Nein. EUDI-Zertifizierung ist notifizierten nationalen Wallet-Schemata und qualifizierten Vertrauensdienstanbietern unter eIDAS 2.0 vorbehalten. CodeB ist ein Verifier (Relying Party), kein Wallet-Issuer, und behauptet keine Zertifizierung, die nicht vorliegt. Die OpenID-Foundation-Selbstzertifizierung für OID4VP 1.0 + HAIP 1.0 ist in Arbeit.

Wie werden Passwörter gespeichert?

Als HA1-Digests — MD5(user:realm:password) nach RFC 2617, das Format das SIP-Softphones bereits nutzen. Klartextpasswort erreicht niemals den Server; das Login-Formular hasht es im Browser. HA1 wird als passwort-äquivalentes Geheimnis behandelt. Reine Web-/OIDC-Deployments ohne SIP können stattdessen Argon2 / scrypt aktivieren.

Kann ich Signaturschlüssel ohne Downtime rotieren?

Ja. Zwei Signaturschlüssel können gleichzeitig aktiv sein. private-key.xml in private-key-previous.xml umbenennen; der nächste Request generiert einen frischen aktiven Schlüssel. JWKS publiziert beide, die kid in jedem Token bindet es an den richtigen. Kein IIS-Recycle, keine abgebrochenen Sessions.

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

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. Für reine Web-/OIDC-Deployments ohne SIP-Softphones kann ein moderner KDF (Argon2 / scrypt / PBKDF2-SHA256) aktiviert werden — bei Setup ansprechen.

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

Authentifizierungsfaktor 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","mfa"] für Smartcard via CP V2 — 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

CP-V2-Smartcard-Anmeldung

Betreiber, die den Aloaha Credential Provider V2 einsetzen, können einen Trust-Schlüssel unter App_Data/<tenant>/oidc/cp-v2-trust.xml ablegen und eine signierte Assertion an /authorize übergeben — Nutzer überspringen das Login-Formular komplett, und die ausgestellten Tokens tragen amr: ["hwk","mfa"].

Hardware-Faktor

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.

Endpunkt	Zweck
/.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

Frage	Antwort
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 →