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

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.

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.

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 →