Skip to main content
Die OIDC-Anmeldung wird vom web-Dienst (dem authentication-Modul) in jedem Ayakaleaf-Pro-Pod abgewickelt. Sie hat keinen Hintergrundjob und keinen separaten Pod. Die Anbieterseite (Client, Redirect-URIs, Administrator-Claim) ist dieselbe wie beim Toolkit; richten Sie daher zuerst Ihren OpenID Provider (OP) gemäß OIDC-Authentifizierung ein und übertragen Sie die Werte dann wie unten gezeigt in Kubernetes.

Wo was läuft

Konfiguration

1

Overleaf beim OP registrieren

Erlauben Sie in Ihrem OP diese Adressen, die aus OVERLEAF_SITE_URL gebildet werden:Die fünf URLs finden Sie im Discovery-Dokument des OP, wie unter Die Werte mit dem Discovery-Dokument ermitteln beschrieben.
2

Die Einstellungen zur ConfigMap hinzufügen

Fügen Sie Folgendes zu overleaf-env hinzu (30-config.yaml bzw. 60-config.yaml für mehrere Replikate):
30-config.yaml (additions)
EXTERNAL_AUTH akzeptiert eine durch Leerzeichen getrennte Liste, zum Beispiel ldap oidc. Unter Umgebungsvariablen finden Sie jede OVERLEAF_OIDC_*-Einstellung; alle gehören in die ConfigMap, außer dem Client Secret.
Setzen Sie "true" und "false" in Anführungszeichen: Eine ConfigMap enthält nur Zeichenketten. Ein auf "" gesetzter Schlüssel ist nicht dasselbe wie ein fehlender Schlüssel: OVERLEAF_OIDC_ALLOWED_EMAIL_DOMAINS: "" deaktiviert die Kontoerstellung bei der ersten Anmeldung, während das Weglassen des Schlüssels jede Domain erlaubt.
3

Das Client Secret in das Secret eintragen

4

Einer privaten CA vertrauen (optional)

Wenn das Zertifikat des OP von Ihrer eigenen CA stammt, fügen Sie die CA zum Secret overleaf-certs hinzu, das unter /var/lib/overleaf/certs eingehängt ist (siehe Zertifikate und andere Dateien), und verweisen Sie Node.js darauf:
5

Anwenden und neu starten

Prüfen Sie anschließend, ob jeder Pod den Token-Endpunkt erreicht. Die Pods rufen ihn auf, nicht der Browser, daher zeigt sich ein Firewall- oder DNS-Problem nur hier:
Jeder HTTP-Status (405 für ein GET) bedeutet, dass der Endpunkt erreichbar ist; 000 bedeutet, dass er es nicht ist.

Mehrere Replikate

Nichts weiter. Der state-Wert einer Anmeldung und das für die Abmeldung verwendete ID-Token werden in der Sitzung gespeichert, die in Redis liegt, sodass der Callback auf jedem Replikat funktioniert, das ihn empfängt.

Getestet auf Kubernetes

Mit goauthentik als OP bestehen auf Kubernetes 1.37 mit drei Replikaten hinter HAProxy unsere End-to-End-Tests für OIDC (35 Fälle): Anmeldung und Abmeldung über den OP; die Administratorzuordnung per Gruppe, per E-Mail und per Einzelwert sowie ohne Zuordnung; Name und Administrator-Flag bei jeder Anmeldung aktualisiert; Verknüpfen und Trennen von Konten; Zurücksetzen und Ändern von Passwörtern von OIDC-Konten; gesperrte Konten; OVERLEAF_OIDC_ALLOWED_EMAIL_DOMAINS; OVERLEAF_DISABLE_LOCAL_LOGIN; sowie OIDC zusammen mit öffentlichem Zugriff.

Q&A

Antwort: Der Browser hat das Sitzungscookie nicht mit dem Callback zurückgesendet. Auf Kubernetes sind die üblichen Ursachen:
  • OVERLEAF_SECURE_COOKIE ist gesetzt, aber Benutzer öffnen die Site über einfaches HTTP, sodass der Browser das Cookie nie speichert. Jeder Wert von OVERLEAF_SECURE_COOKIE, selbst "false", aktiviert sichere Cookies; entfernen Sie stattdessen den Schlüssel.
  • Die Site wird unter einer anderen Adresse als OVERLEAF_SITE_URL geöffnet.
  • Hinter HTTPS sendet Ihr Ingress oder Load Balancer kein X-Forwarded-Proto: https, oder seine Adresse fehlt in OVERLEAF_TRUSTED_PROXY_IPS.
Antwort: Im web-Log des Pods, der die Anfrage bearbeitet hat, nicht in kubectl logs:
Prüfen Sie bei mehreren Replikaten jeden overleaf-N.
Zuletzt geändert am 2. November 2026