Pocket-ID: Ein OIDC-Provider, der nur eine Sache kann — und die gut

Permalink 3 min read Published:
 infrastructure  security  #pocket-id #oidc #authentik #sso #passkey #webauthn #kubernetes #gitops
Warum ich meinen schwergewichtigen Authentik-Stack gegen das schlanke, passkey-zentrierte Pocket-ID als zentralen OIDC-Provider getauscht habe
Table of contents

Single Sign-On im Homelab ist ein zweischneidiges Schwert: Man will einen Login für alles, handelt sich damit aber schnell einen Identity-Provider ein, der schwerer wiegt als die Dienste, die er absichert. Genau an diesem Punkt habe ich meinen bisherigen Authentik -Stack gegen Pocket-ID getauscht — erreichbar unter auth.this-is-fine.io und seitdem der zentrale OIDC-Provider für mein gesamtes Lab.

Warum Authentik weichen musste

Authentik ist exzellente Software und ein vollwertiger Identity-Provider: SAML, OAuth2/OIDC, LDAP, ausgefeilte Authentication-Flows, Policy-Engine, Outposts für Proxy-Auth. Genau diese Mächtigkeit hat aber ihren Preis. Im Cluster bedeutete Authentik einen server, einen worker, eine PostgreSQL-Datenbank und einen Redis-kompatiblen Cache — ein kleiner verteilter Stack, nur damit ich mich irgendwo einloggen kann.

Für eine Organisation mit hunderten Nutzern, SAML-Zwang und komplexen Föderationsanforderungen ist das angemessen. Für mein Lab, in dem genau ein Mensch und eine Handvoll Dienste OIDC sprechen, war es schlicht überdimensioniert. Die ehrliche Erkenntnis: Ich nutzte vielleicht fünf Prozent der Features und betrieb hundert Prozent der Komplexität.

Das ist ausdrücklich kein Argument gegen Authentik — wer SAML, LDAP-Outposts oder feingranulare Flow-Policies wirklich braucht, ist dort goldrichtig aufgehoben. Es ist ein Argument für die richtige Werkzeuggröße: Man sollte die Komplexität bezahlen, die man auch verbraucht.

Was Pocket-ID anders macht

Pocket-ID dreht die Prioritäten um: Es ist ein reiner OIDC-Provider, bewusst auf das Nötigste reduziert. Kein SAML, kein LDAP, keine Flow-Engine — dafür ein einzelner Prozess, der seinen Zustand in einer SQLite-Datei hält. Kein externer Datenbank-Cluster, kein Cache-Deployment, keine Outposts.

Der zweite, eigentlich charmante Aspekt ist die Authentifizierung selbst: Pocket-ID ist von Grund auf passkey-zentriert und setzt auf WebAuthn /FIDO2. Statt Passwörter zu verwalten, melde ich mich mit einem Hardware- oder Plattform-Authenticator an — phishing-resistent und ohne Passwort-Datenbank, die geleakt werden könnte.

Im Cluster ist das Deployment entsprechend unspektakulär: ein Container, eine APP_URL, fertig.

image: ghcr.io/pocket-id/pocket-id:v2.5.0
env:
  - name: APP_URL
    value: "https://auth.${EXTERNAL_DOMAIN}"

Nach außen hängt der Dienst über eine HTTPRoute am Envoy-Gateway unter auth.this-is-fine.io, mit TLS aus cert-manager. Das war der gesamte operative Aufwand.

Ein Provider für alles

Der eigentliche Gewinn zeigt sich erst im Zusammenspiel: Pocket-ID ist heute die eine Stelle, an der sich Menschen im Lab ausweisen. Jeder Dienst, der OIDC spricht, hängt als Client daran:

flowchart TB PID["Pocket-ID<br/>auth.this-is-fine.io<br/>(SQLite · Passkeys)"] HS["Headscale<br/>(Tailnet-Enrollment)"] ZOT["Zot-Registry<br/>(Web-UI-Login)"] EG["Envoy-Gateway<br/>(OIDC für Apps ohne SSO)"] GRAF["Grafana, …<br/>(via SecurityPolicy)"] HS -->|"OIDC client"| PID ZOT -->|"OIDC client"| PID EG -->|"SecurityPolicy oidc"| PID GRAF --- EG
  • Headscale nutzt Pocket-ID für das Tailnet-Enrollment von Menschen — keine manuellen Pre-Auth-Keys mehr, nur noch OIDC-Login, Maschinen behalten ihre getaggten Keys.
  • Die Zot-Registry bindet Pocket-ID für den Web-UI-Login der Menschen an, während Maschinen weiterhin über htpasswd authentifizieren.
  • Das Envoy-Gateway kann über eine SecurityPolicy sogar Diensten ein OIDC-Login vorschalten, die selbst gar kein SSO können — die Anmeldung passiert dann am Gateway, lange bevor der Request die App erreicht.

Fazit

Der Wechsel von Authentik zu Pocket-ID hat mir nicht ein einziges Feature genommen, das ich tatsächlich genutzt habe — wohl aber einen PostgreSQL-Cluster, einen Cache und einen Worker erspart. Übrig bleibt ein einzelner, passkey-erster Prozess, der genau eine Aufgabe erfüllt und sie aus dem Weg geht. Manchmal ist die beste Architekturentscheidung schlicht, das kleinere Werkzeug zu nehmen.