pacod-id

pacod-id ist der OpenID Connect Provider hinter den PACOD-Produkten: ein gemeinsamer Kontenpool, gehostete Anmelde- und Kontoseiten, Organisationen und Rollenzuweisungen. Seine Tokens sagen, wer jemand ist, nicht, was er darf: Jedes Produkt folgt einem Feed der Rollenzuweisungen und entscheidet selbst über den Zugriff, mit einer Regel-Engine in Rust, TypeScript und Python.

Funktionen

Screenshots

Warum es pacod-id gibt

Jedes Produkt, das Menschen hereinlässt, endet mit eigenen Passwörtern, Konto-Mails, Verwaltungsseiten und Rollentabellen, und jeder Mensch mit einem Konto pro Produkt. pacod-id nimmt den Produkten all das ab. Man meldet sich einmal an und erreicht mit demselben Konto die Gateway-Konsole, die Agentenplattform, das CMS-Studio, die Wissensdatenbank und die Benchmarks. Auch Maschinen melden sich an, als Servicekonten.

pacod-id ist ein OpenID Connect Provider für deine eigenen Anwendungen. Jeder Client steht in seiner Konfiguration: Es gibt keine dynamische Registrierung und keinen Zustimmungsdialog. Alle Konten liegen in einem Pool, und das sub einer Person ist in jedem Realm dasselbe. Von Produkt zu Produkt unterscheiden sich das Aussehen der Anmeldung und die Frage, wer dort was darf, und pacod-id hält beides fest.

Realms, Marken und Clients

Ein Realm ist ein Issuer-Host mit eigener Marke, eigenem Anmelde-Cookie, eigenen Sprachen und Richtlinien: Mindestlänge der Passwörter, Sitzungsdauer, ob sich jeder registrieren darf und welche Rollen Konten verwalten. pacod-id wählt den Realm anhand des Host der Anfrage, sodass zwei Realms einen Kontenpool teilen und trotzdem wie zwei Produkte aussehen können.

Die Marke eines Realms ist eine von fünf eingebauten: gateway, cms und kb für die PACOD-Produkte sowie shop und bazaar für das fiktive Produkt, das Dokumentation und Tests verwenden. Sie bestimmt Zeichen, Schriftzug und Farben der Seiten und das Layout der Mails. Die Marke gehört zum Realm, nicht zum Client: Jede Anwendung eines Realms zeigt dasselbe Aussehen. pacod-demo betreibt einen Realm, pacod, für alle Produkte und gibt ihm die Marke des Gateways. Deshalb tragen seine Anmelde- und Kontoseiten das Zeichen von pacod-gw, egal welches Produkt die Person geschickt hat.

Ein Client ist eine Anwendung, von einer von drei Arten:

Art	Typischer Einsatz	Grants
confidential	Das Backend-for-Frontend eines Produkts, das ein Geheimnis hält	authorization_code, refresh_token
public	Eine native oder mobile App; nur PKCE schützt ihre Codes	authorization_code, refresh_token
service	Der Server eines Produkts, der mit pacod-id spricht	client_credentials, Token Exchange

Eine Anmeldung, Schritt für Schritt

1. Das Produkt beginnt sie. Sein Server schickt den Browser zu /oidc/authorize, mit state, einer nonce und einer PKCE-Challenge. Angeboten wird nur der Authorization-Code-Flow, und PKCE (S256) ist für jeden Client Pflicht, auch für vertrauliche.
2. pacod-id prüft die Anfrage. Der Realm ergibt sich aus dem Host; der Client muss zu ihm gehören, und die Redirect-URI muss exakt einer registrierten entsprechen. Solange beides nicht feststeht, zeigt ein Fehler eine Fehlerseite und leitet nie weiter.
3. Single Sign-on oder ein Ablauf. Eine lebende Sitzung des Realms bekommt sofort einen Code. Sonst speichert pacod-id die Anfrage 15 Minuten als Anmeldeablauf, bindet ihn per Cookie an den Browser und schickt den Browser auf seine gehostete Seite /login.
4. Die Person meldet sich an, mit Passwort oder, wo der Realm es anbietet, mit Google. Jeder Versuch belegt seinen Platz in den Drosseln in PostgreSQL, bevor das Passwort gehasht wird, und eine unbekannte Adresse bekommt dieselbe Antwort wie ein falsches Passwort. Muss die Adresse erst bestätigt oder das Passwort geändert werden, führt der Ablauf dorthin.
5. Eine Sitzung und ein Code. Die Anmeldung legt eine neue SSO-Sitzung an (12 Stunden, oder 7 Tage mit „angemeldet bleiben“) und einen Code, der 60 Sekunden lebt, einmal gilt und an Client, Redirect-URI und PKCE-Challenge gebunden ist. Der Browser kehrt mit code, state und iss zum Produkt zurück.
6. Das Produkt löst ihn ein, an /oidc/token, meist auf dem internen Listener, und erhält ein Access-Token, ein id_token und ein Refresh-Token. Ihr Issuer bleibt die öffentliche URL des Realms.

Tokens

• Access-Tokens sind JWTs (RFC 9068), RS256 oder ES256 je Client, standardmäßig 5 Minuten gültig (2 bis 15). Sie sagen, wer, in welcher Sitzung und mit welchem Scope, tragen aber keine Rollen.
• id_tokens leben 5 Minuten und enthalten Adresse und Namen, wenn die Scopes danach fragen.
• Refresh-Tokens sind opak und rotieren bei jeder Nutzung. Ein Token, das innerhalb von 30 Sekunden erneut vorgelegt wird, bekommt denselben Nachfolger, sodass zwei Tabs gleichzeitig erneuern können. Ein älteres beendet alle Sitzungen des Kontos, meldet das allen Produkten und schreibt dem Inhaber eine Mail.
• Service-Tokens (pidt_…) gehören Servicekonten, werden einmal angezeigt und als HMAC gespeichert.
• Token Exchange (RFC 8693) lässt den Dienst eines Produkts für eine Person handeln, im Rahmen ihrer Rechte, wobei act den Dienst nennt. Eine delegierte Berechtigung endet mit der Sitzung der Person.

Endet eine Sitzung, erhält jeder Client, der darin eine Berechtigung hatte und eine Back-Channel-Logout-URI hat, ein Logout-Token, das zehn Minuten lang erneut zugestellt wird.

Rollen bleiben aus den Tokens heraus

Rollen stehen absichtlich nicht in Access-Tokens: Eine entzogene Rolle soll sofort nicht mehr zählen, nicht erst, wenn ein Token abläuft. Jedes Produkt schickt bei jedem Start ein Manifest: seine Scope-Typen, seine Rollen mit ihren Berechtigungen und wer was vergeben darf. Scopes bilden einen Baum, von platform, wahlweise über organisation:<id>, bis zu den eigenen Typen des Produkts. Das ist das des Gateways, gekürzt:

product: gw
scope_types:
  workspace: { parent: organisation }
roles:
  platform_admin:
    at: [platform]
    permissions: ["*"]
    protected: true
  org_admin:
    at: [organisation]
    permissions: [org.manage, org.read, workspace.manage, workspace.read,
                  audit_records.read, audit_log.read, members.manage]
    protected: { bypass: platform.manage }
  viewer:
    at: [platform, organisation, workspace]
    permissions: [org.read, workspace.read]
grant:
  default: members.manage
  platform_admin: platform.manage

Eine Zuweisung ist eine Rolle an einem Scope, etwa gw.viewer an gw.workspace:ws_1, und ihre Berechtigungen gelten nach unten: Eine Rolle an einer Organisation zählt in jedem Workspace darunter. pacod-id speichert die Zuweisungen und prüft jede Änderung. Eine Rolle zu vergeben braucht die Vergabe-Berechtigung des Manifests an diesem Scope (hier vergeben Organisations-Admins Rollen in ihrer Organisation, und nur ein Plattform-Admin macht Plattform-Admins), und eine protected-Rolle verliert nie ihren letzten Inhaber. Wo ein Manifest es erlaubt, können die Admins des Produkts eigene Rollen anlegen, die selbst keine Berechtigung geben, aber für has_role zählen.

pacod-ids eigenes Manifest ist eingebaut: id.admin darf in pacod-id alles und ist geschützt, id.auditor liest Konten und das Audit-Log. Ein Realm kann außerdem Produktrollen nennen, deren Inhaber die dort registrierten Konten verwalten; die Demo nennt die Administratoren der Produkte. Ein solcher Administrator verwaltet nur Konten, deren Rollen er alle selbst hätte vergeben können, sodass der Admin eines Produkts keinen Identitäts-Admin übernehmen kann.

Die Regel-Engine beantwortet unter anderem allowed, has_role, touches und can_grant. Es gibt sie in Rust, TypeScript und Python, und alle drei bestehen dieselben YAML-Testvektoren (policy/engine-vectors/). Die Vektoren sind die Spezifikation, also fällt eine Entscheidung überall gleich aus.

Der Autorisierungs-Feed

Jedes Produkt hält eine eigene Kopie der Zuweisungen und folgt den Änderungen:

1. Beim Start lädt es einen Snapshot: seinen Katalog, die Organisationen und seine eigenen Scopes, die Zuweisungen seiner Rollen und der id.*-Rollen, deaktivierte und gelöschte Konten und die in den letzten 15 Minuten widerrufenen Sitzungen, alles zum Stand einer Sequenznummer, seq.
2. Danach fragt es per Long Poll die Änderungen nach dieser seq ab und wartet bis zu 30 Sekunden pro Aufruf. Die Antwort kommt, sobald sich etwas ändert: PostgreSQL LISTEN weckt die wartende Anfrage.
3. Änderungen werden 7 Tage aufbewahrt. Ein älterer Cursor bekommt eine 410, und das Produkt lädt den Snapshot neu.

{
  "seq": 1843,
  "events": [
    { "seq": 1843, "kind": "binding.removed", "principal": "usr_0191…", "role": "gw.viewer",
      "path": ["platform", "organisation:org_1", "gw.workspace:ws_1"] }
  ]
}

Die Ereignisse betreffen Zuweisungen, Konten (deaktiviert, aktiviert, gelöscht, geändert), Sitzungen, Service-Tokens, Scopes und Kataloge. Schreibvorgänge antworten mit der seq des Feeds, sodass ein Produkt, das seinen eigenen Schreibvorgang lesen muss, wartet, bis seine Kopie aufgeholt hat. Die Client-Bibliotheken für Rust und Python erledigen all das in ihrem Zuweisungs-Cache. Access-Tokens tragen die sid der Sitzung, die ein Produkt ablehnt, sobald der Feed ihren Widerruf meldet.

Gemessen mit make measure auf einem Entwicklerrechner (Docker Desktop auf Apple Silicon) erreichte eine Änderung einen wartenden Follower mit einem p99 von etwa 10 ms, bei einem Ziel von unter einer Sekunde. Das ist pacod-ids eigener Anteil: Das Ziel der Produkte, zwei Sekunden von der Abmeldung bis zur Ablehnung, hängt vom Follower jedes Produkts ab.

Die Teile

Teil	Was
crates/pacod-id	Der Dienst: OpenID Connect Provider, Konten, Organisationen, Rollenzuweisungen, der Autorisierungs-Feed, Mail, Audit
crates/pacod-id-authz	Die Regel-Engine
crates/pacod-id-jose	Compact JWS (RS256, ES256) auf ring, und JWKS
crates/pacod-id-client	Token-Prüfung, Zuweisungs-Cache, Introspection und Token Exchange für Rust-Produkte
python/	Das Paket pacod_id: Regel-Engine, Token-Prüfung, Zuweisungs-Cache, FastAPI-Dependencies
packages/*	@pacod/id-authz, @pacod/ui, @pacod/id-client, @pacod/id-sveltekit
ui/	Die gehosteten Anmelde-, Konto- und Verwaltungsseiten

Der Dienst ist ein Rust-Binary auf axum mit drei Listenern:

Listener	Port	Für
public	8070	Browser und Apps, über einen TLS-Reverse-Proxy: die OpenID-Connect-Endpunkte und die gehosteten Seiten
internal	8071	Nur die Server der Produkte: Tokens, der Feed, Introspection, Sitzungswiderruf, die Admin-API
metrics	9170	/healthz, /readyz und /metrics

Die gehosteten Seiten sind ein statischer SvelteKit-Build, den das Binary selbst ausliefert, mit Marke, Sprache und Design des Realms schon vor dem ersten Rendern. Dort finden Menschen Profil, Passwort, Geräte und Sitzungen, Anmeldemethoden sowie Organisationen und Rollen; Administratoren finden Konten, Servicekonten und das Audit-Log. @pacod/ui enthält die Design-Tokens, Markenthemen und Anmeldekomponenten, die die Produkte mit pacod-id teilen können.

Sicherheitsmodell

Die wichtigsten Kontrollen aus dem Bedrohungsmodell:

• Passwörter: Argon2id auf dem Minimum von OWASP (19 MiB, 2 Durchläufe), standardmäßig 12 Zeichen, und eine Sperrliste von 46.528 gängigen Passwörtern. Die Anmeldedrosseln liegen in PostgreSQL und gelten für alle Instanzen: pro Konto, pro bekanntem Browser und pro IP-Adresse.
• Keine Kontoabfrage: Anmeldung, Passwort-Reset und Registrierung antworten gleich, ob es zu einer Adresse ein Konto gibt oder nicht.
• Signaturschlüssel: von pacod-id erzeugt, in der Datenbank unter einem Key-Encryption-Key (PID_KEK) versiegelt, alle 90 Tage rotiert, der nächste Schlüssel einen Tag früher veröffentlicht. Eine Notrotation ist ein Befehl.
• Gespeicherte Geheimnisse: Refresh-Tokens und Mail-Links als SHA-256, Client-Geheimnisse und Service-Tokens als HMAC unter einem eigenen Pepper. pacod-ids eigene Logzeilen enthalten nie ein Passwort, Token oder einen Schlüssel, und es schreibt keine Zeile pro Anfrage.
• Browser-Abläufe: PKCE, state, nonce und iss bei jeder Weiterleitung; exakte Redirect-URIs; eine Content-Security-Policy aus den Hashes der Skripte der Seiten; Schreibvorgänge nur vom eigenen Origin des Realms.
• Erreichbarkeit: Der öffentliche Listener bedient keine internen oder Admin-Routen. Im vollen pacod-Stack bindet der interne Listener an pacod-id-internal, einen Alias, den pacod-id nur im internen Netz pacod-admin-net hat, dem nur die Server der Produkte beitreten. Die NetworkPolicy des Helm-Charts lässt den internen Port nur aus den Quellen zu, die du angibst.
• Image: ein statisches musl-Binary auf distroless, ohne Root-Rechte und ohne Shell.

Das Bedrohungsmodell nennt auch, was bleibt, jeweils als offen oder akzeptiert markiert: Der interne Listener spricht reines HTTP, der Dienst jedes Produkts darf jede Sitzung beenden, und die Produkte teilen sich die Organisationen.

Betrieb

Realms und Clients stehen in einer TOML-Datei, Geheimnisse nie. Das Geheimnis eines Clients kommt aus der Variable, die sein secret_env nennt, und ${NAME} übernimmt einen Wert aus der Umgebung.

[[realm]]
name = "gateway"
issuer = "https://id.example.com"
brand = "gateway"
locales = ["en", "bg", "de", "ru"]
self_signup = false

[[client]]
id = "pacod-gw-console"
realm = "gateway"
kind = "confidential"
secret_env = "PGW_UI_CLIENT_SECRET"
redirect_uris = ["https://console.example.com/auth/callback"]
audience = "pacod-gw"

pacod-id check-config prüft die Datei ohne Datenbank. Darüber hinaus braucht der Dienst PID_DATABASE_URL, PID_KEK und PID_TOKEN_PEPPER, jeweils als Variable, Datei oder in einem Geheimnis-Verzeichnis.

• Datenbank: PostgreSQL, mit einer eigenen Rolle, die kein Superuser ist. Migrationen fügen nur hinzu und laufen bei jedem Start unter einem Advisory Lock.
• Instanzen: beliebig viele teilen sich eine Datenbank. Jede verschickt fällige Mails und Logouts und lädt Schlüssel und Kataloge neu; eine, die einen Lease hält, rotiert Schlüssel und räumt alte Zeilen ab.
• Mail: Keine Anfrage wartet auf SMTP. Mails gehen in eine Outbox, in Marke und Sprachen des Realms, und werden etwa acht Stunden lang erneut versucht.
• Erster Administrator: wird beim Start aus PID_BOOTSTRAP_ADMIN_* angelegt, standardmäßig mit id.admin.
• Überwachung: /readyz prüft die Datenbank und den Signaturschlüssel; /metrics liefert Anfragezahlen und -dauern pro Listener. Die Logs folgen dem gemeinsamen pacod-Format, eine JSON- oder Textzeile pro Ereignis. Anmeldungen, Rollenänderungen und Aktionen von Administratoren gehen in ein Audit-Log, das 400 Tage aufbewahrt wird und in der Verwaltung lesbar ist.

Ein Gateway, das Personen selbst angemeldet hat, kann sie mit pacod-id import gw übergeben: Passwörter, Admin-Tokens und Einladungslinks funktionieren weiter, und bis es abschließt, kann das Gateway zu seiner eigenen Anmeldung zurückkehren, solange sich hier seitdem nichts geändert hat.

Im pacod-Stack

make compose-up startet einen Entwicklungs-Stack: einen Realm shop unter http://127.0.0.1:26070 mit offener Registrierung, eine Mail-Senke und einen Ersatz für Google, alles nur auf 127.0.0.1 veröffentlicht. Wie jedes pacod-Projekt tritt pacod-id dem gemeinsamen Docker-Netz pacod-net bei, und sein Compose-Setup hat zwei Dateien. docker-compose.yml enthält nur pacod-id; docker-compose.standalone.yml fügt eigene Kopien der gemeinsamen Komponenten hinzu: PostgreSQL (pacod-postgres), pacod-db-init, das die Rolle pacod_id und ihre Datenbank anlegt, wenn sie fehlen, eine Mail-Senke (pacod-mailpit) und den Google-Mock (id-mock-idp).

Der volle pacod-Stack, pacod-demo, lädt nur die erste Datei. Er betreibt ein PostgreSQL, eine Mail-Senke, einen Edge und ein pacod-id für alle Produkte, mit einem einzigen Realm und den eigenen Clients der Produkte: je einem Anmelde-Client und einem Service-Client für die App, das Gateway, das Studio, die Wissensdatenbank und die Benchmarks. platform/ enthält pacod-ids Anteil an dieser Konfiguration: sein Datenbankskript, seine Route im gemeinsamen Caddy und seinen Prometheus-Job.

Was getestet ist und was noch fehlt

• make verify führt Formatierung, Linter, Typprüfungen und alle Tests in Rust, TypeScript und Python aus. Die CI prüft außerdem die Abhängigkeiten, baut das Image, startet den Entwicklungs-Stack, prüft die Latenzziele und lintet das Helm-Chart.
• make e2e führt die gehosteten Seiten und drei Fixture-Anwendungen in einem echten Browser aus, mit drei Realms, der Mail-Senke und dem Google-Mock, und geht jede Marke hell und dunkel durch. Es läuft lokal, nicht in der CI.
• Die Konformitäts-Suite der OpenID Foundation (v5.3.2) lief lokal: die Pläne Config, Basic und RP-Initiated Logout ohne fehlgeschlagene Bedingung unter 2.370 geprüften, während ein Test für Back-Channel Logout am selbstsignierten Zertifikat der Suite hängen blieb. Lokale Läufe sind keine Zertifizierung.
• pacod-id 0.1.0 ist noch nicht veröffentlicht. Upgrades, Backup und Wiederherstellung wurden noch nicht durchgespielt.
• Das Helm-Chart besteht helm lint und Schemaprüfungen, wurde aber noch auf keinem Cluster installiert. Ein echter SMTP-Server und das echte Google wurden nicht ausprobiert, der Mock des Entwicklungs-Stacks schon.
• Noch kein MFA und keine Passkeys, daher kein acr-Claim. Bis sie kommen, handeln die gehosteten Verwaltungsseiten allein auf das Sitzungscookie hin, ohne eine frische Anmeldung zu verlangen.
• Keine Adress- oder Telefon-Claims; der Scope profile liefert name und locale.
• Es gibt kein allgemeines Rate Limit über die Anmeldedrosseln hinaus, und Images sind noch nicht signiert und kommen ohne SBOM.

Weiterlesen

• Runbook: Installation und Betrieb.
• HTTP-API: jeder Endpunkt und die Ereignisse des Feeds.
• Bedrohungsmodell: Kontrollen und verbleibende Risiken.
• Messungen: Latenz des Token-Endpunkts und des Feeds.
• Konformitätsergebnisse und die Testvektoren der Regel-Engine.

Schnellstart

Entwickeln und testen

make test-services
make verify
make e2e

Image bauen und starten

make image
make compose-up

Funktioniert mit

• pacod-gw: Mit PGW_AUTH=oidc meldet die Konsole Personen über pacod-id an; der Kern schickt die gw-Rollen, registriert Organisationen und Workspaces und folgt dem Feed.
• pacod-ap: Die App und ihre Admin-Konsole melden sich über pacod-id an; die API schickt die pacod-Rollen und folgt dem Feed, sodass App und Gateway-Konsole ein Konto teilen.
• pacod-cms: Das Studio meldet Personen über pacod-id an, das ihre Rollen pro Organisation und pro Website hält.
• pacod-kb: Die Oberfläche meldet Personen über pacod-id an; die Rollen Viewer, Editor und Admin werden dort vergeben.
• pacod-benchmark: Die Oberfläche meldet Personen über pacod-id an, und die API prüft jeden Aufrufer gegen ihre Rollen Viewer, Operator und Admin, die sie bei jedem Start schickt.