Authentik OIDC: Vaultwarden, Immich & Nextcloud anbinden

Was am Ende steht

Authentik übernimmt per OIDC die Anmeldung, die Apps behalten ihre Benutzerkonten. Für jede App legen Sie in Authentik ein Paar aus Provider (OAuth2/OpenID) und Application an, tragen die Redirect-URI der App ein und kopieren Client-ID und Client-Secret in die Konfiguration der App. Das Muster ist bei Vaultwarden, Immich, Nextcloud, Grafana und Paperless-ngx dasselbe. Nur die Stelle, an der die Werte landen, unterscheidet sich: mal eine Umgebungsvariable in der docker-compose.yml, mal ein Formular in der Admin-Oberfläche.

Diese Anleitung setzt voraus, dass Authentik bereits läuft und über TLS erreichbar ist. Wie Sie dorthin kommen, steht in Authentik als eigenen SSO-Server auf dem VPS aufsetzen. Hier geht es nur um die Anbindung. Alle Beispiele nutzen https://auth.example.com für Authentik und je eine eigene Subdomain pro App. Geprüft wurden die Angaben am 20. September 2026 gegen die jeweilige Dokumentation: Authentik 2026.8, Vaultwarden 1.37, Immich 3.2, user_oidc 8.x für Nextcloud, Grafana 13.2 und Paperless-ngx 3.2.

Ein Punkt vorweg, weil er die Auswahl der fünf Apps erklärt: Bei keiner davon kostet der OIDC-Login Geld. Bitwarden verkauft „Login mit SSO“ (Stand September 2026) nur im Enterprise-Plan, Vaultwarden liefert es seit Version 1.35.0 kostenlos mit. Nextcloud, Grafana, Immich und Paperless-ngx haben OIDC in der freien Ausgabe. Wo eine Funktion rund um SSO doch hinter einer Bezahlschranke liegt, steht es im jeweiligen Abschnitt. Warum das bei vielen anderen Programmen anders ist, erklärt die SSO-Steuer bei selbst gehosteten Apps.

Das OIDC-Muster in Authentik: Provider, Application, Redirect-URI

OIDC (OpenID Connect) ist eine Schicht über OAuth 2.0. Die App schickt den Browser zu Authentik, Authentik prüft die Anmeldung und schickt den Browser mit einem Code zurück an die App. Die App tauscht den Code gegen Tokens und liest daraus, wer sich angemeldet hat. Zurückgeschickt wird der Browser nur an eine Adresse, die im Provider hinterlegt ist. Diese Adresse heißt Redirect-URI, und sie ist die häufigste Fehlerquelle.

So legen Sie das Paar in der Admin-Oberfläche von Authentik an:

1. Öffnen Sie Applications > Applications und klicken Sie auf Create with Provider. Der Assistent legt Application und Provider in einem Durchgang an.
2. Vergeben Sie einen Namen und merken Sie sich den Slug. Der Slug wird Teil der Issuer-URL, die jede App braucht.
3. Wählen Sie als Provider-Typ OAuth2/OpenID Provider. Als Authorization flow passt default-provider-authorization-implicit-consent, dann sieht der Nutzer keine Zustimmungsseite.
4. Lassen Sie den Client type auf Confidential. Alle fünf Apps laufen auf dem Server und können ein Secret geheim halten. Kopieren Sie Client ID und Client Secret sofort, das Secret zeigt Authentik später nur noch in der Bearbeitungsansicht.
5. Tragen Sie unter Redirect URIs/Origins die Adresse der App ein, Modus Strict. Welche das ist, steht in jedem App-Abschnitt.
6. Wählen Sie unter Signing Key das Zertifikat authentik Self-signed Certificate. Ohne Signing Key stellt Authentik kein signiertes ID-Token aus, und die Anmeldung scheitert an der Token-Prüfung der App.
7. Öffnen Sie Advanced protocol settings. Dort stehen die Scopes (openid, email und profile müssen ausgewählt sein), der Subject mode und die Gültigkeit der Tokens.

Wenn Sie das Feld für die Redirect-URIs leer lassen, speichert Authentik die erste URI, die eine App benutzt. Das ist bequem beim Ausprobieren und gefährlich im Betrieb, weil dann die erste Anfrage entscheidet, wohin Tokens geschickt werden dürfen. Tragen Sie die URI ein.

Nach dem Speichern gibt es pro Application diese Adressen. <slug> ist der Slug aus Schritt 2:

• Issuer: https://auth.example.com/application/o/<slug>/
• Discovery-Dokument: https://auth.example.com/application/o/<slug>/.well-known/openid-configuration
• Authorize: https://auth.example.com/application/o/authorize/
• Token: https://auth.example.com/application/o/token/
• Userinfo: https://auth.example.com/application/o/userinfo/
• Abmelden: https://auth.example.com/application/o/<slug>/end-session/

Der Schrägstrich am Ende der Issuer-URL gehört dazu. Authentik trägt im Discovery-Dokument genau diesen Wert als issuer ein, und Clients vergleichen den Wert Zeichen für Zeichen. Bei Vaultwarden muss SSO_AUTHORITY laut Wiki exakt dem Issuer entsprechen, sonst scheitert schon die Discovery.

Eine Stichprobe, bevor Sie eine App anfassen:

curl -s https://auth.example.com/application/o/<slug>/.well-known/openid-configuration | jq .issuer

Kommt hier der Issuer zurück, stimmen Slug und Erreichbarkeit. Kommt eine Fehlerseite, ist der Slug falsch geschrieben oder die Application nicht gespeichert.

Zum Schluss die Zugriffskontrolle: Ohne Bindung darf sich jeder Authentik-Nutzer an jeder Application anmelden. Legen Sie pro App eine Gruppe an (vaultwarden-users, grafana-admins) und binden Sie die Gruppe unter Applications > Ihre Application > Policy / Group / User Bindings an die Application. Die Gruppennamen tauchen im Token als Claim groups auf, weil das Standard-Mapping für den Scope profile sie mitschickt. Grafana, Nextcloud und Paperless-ngx werten diesen Claim aus.

Vaultwarden: SSO ohne Enterprise-Plan

Vaultwarden kann seit Version 1.35.0 OIDC. Die Konfiguration läuft komplett über Umgebungsvariablen, die Sie in der docker-compose.yml Ihres Vaultwarden-Servers auf dem VPS ergänzen. Redirect-URI in Authentik: https://vault.example.com/identity/connect/oidc-signin. Vaultwarden leitet die URI aus DOMAIN ab, es gibt keinen eigenen Schalter dafür.

Drei Dinge müssen im Authentik-Provider anders sein als im Standard, und alle drei stehen so im Vaultwarden-Wiki und in der Authentik-Integrationsseite:

• Access token validity unter Advanced protocol settings auf mehr als fünf Minuten setzen, zum Beispiel hours=1. Der Grund steht weiter unten bei den Fehlern.
• Den Scope offline_access zusätzlich auswählen. Ohne ihn gibt Authentik kein Refresh-Token heraus, und der Web-Vault kann die Sitzung nicht verlängern.
• Ein eigenes Scope-Mapping für email anlegen. Das mitgelieferte Mapping von Authentik liefert email_verified: False, und Vaultwarden blockiert die Neuanmeldung, wenn der Provider die Adresse als nicht bestätigt meldet.

Das Mapping legen Sie unter Customization > Property Mappings > Create > Scope Mapping an. Name frei wählbar, Scope name email, Ausdruck:

return {
    "email": request.user.email,
    "email_verified": True,
}

Danach im Provider unter Scopes das Standard-Mapping für email abwählen und das eigene auswählen. Dann die Umgebungsvariablen:

services:
  vaultwarden:
    image: vaultwarden/server:latest
    environment:
      DOMAIN: "https://vault.example.com"
      SSO_ENABLED: "true"
      SSO_AUTHORITY: "https://auth.example.com/application/o/vaultwarden/"
      SSO_CLIENT_ID: "<Client ID aus Authentik>"
      SSO_CLIENT_SECRET: "<Client Secret aus Authentik>"
      SSO_SCOPES: "email profile offline_access"
      SSO_SIGNUPS_MATCH_EMAIL: "true"
      SSO_ONLY: "false"

openid müssen Sie in SSO_SCOPES nicht nennen, Vaultwarden hängt es selbst an. SSO_SIGNUPS_MATCH_EMAIL=true verknüpft ein bestehendes Konto mit der SSO-Identität, wenn die E-Mail-Adresse übereinstimmt. Vaultwarden speichert die Identität als {iss}/{sub}, also Issuer plus Subject, und nutzt sie ab dann zur Zuordnung. SSO_ONLY bleibt zunächst auf false, damit Sie sich bei einem Fehler weiter mit dem Master-Passwort anmelden können.

Das Master-Passwort verschwindet mit SSO nicht. Aus ihm wird der Schlüssel abgeleitet, mit dem der Tresor verschlüsselt ist, und Authentik hat diesen Schlüssel nie. SSO ersetzt nur die Prüfung, wer Sie sind. Wer das mit dem Key Connector von Bitwarden vergleicht, findet die Unterschiede in Vaultwarden gegen das offizielle Bitwarden im Selbstbetrieb.

Nach docker compose up -d zeigt der Web-Vault beim Login zusätzlich den SSO-Button. Der Browser springt zu Authentik, meldet sich an und landet wieder im Vault, wo das Master-Passwort abgefragt wird.

Immich: drei Redirect-URIs, sonst nichts Besonderes

Immich konfigurieren Sie in der Web-Oberfläche unter Administration > Settings > OAuth Authentication. Die Felder heißen Issuer URL, Client ID, Client Secret, Scope, Button Text, Auto Register, Auto Launch und Mobile Redirect URI Override. Der Issuer ist https://auth.example.com/application/o/immich/. Den Zusatz .well-known/openid-configuration dürfen Sie weglassen, Immich hängt ihn bei der Discovery selbst an. Scope bleibt auf openid email profile.

In Authentik brauchen Sie drei Redirect-URIs, alle im Modus Strict:

• https://fotos.example.com/auth/login für den Login im Browser
• https://fotos.example.com/user-settings für das Verknüpfen eines bestehenden Kontos
• app.immich:///oauth-callback für die Handy-App

Die dritte ist ein eigenes URL-Schema, und Authentik nimmt es an. Die Handy-App öffnet den System-Browser, meldet sich bei Authentik an und wird über dieses Schema wieder in die App zurückgeholt. Fehlt die URI, funktioniert der Login am Rechner, und die App auf dem Telefon bekommt die Fehlerseite von Authentik.

Auto Register legt für jede neue Authentik-Identität ein Immich-Konto an. Bestehende Nutzer, die ihre Bibliothek behalten wollen, melden sich einmal mit Passwort an und verknüpfen unter Account Settings > OAuth ihr Konto. Dafür ist die zweite Redirect-URI da. Mobile Redirect URI Override ist für Provider gedacht, die kein eigenes URL-Schema als Redirect akzeptieren; bei Authentik bleibt das Feld leer.

Bezahlschranke: keine. Immich verkauft eine freiwillige Supporter-Lizenz, die keine Funktion freischaltet. Wie die Instanz selbst aufgesetzt wird, steht in Immich als eigener Google-Fotos-Ersatz auf dem VPS.

Nextcloud: die App user_oidc

Nextcloud bringt OIDC nicht im Kern mit, sondern über die App OpenID Connect user backend (Paket user_oidc). Sie steht im App-Store, ist AGPL-lizenziert und braucht keine Enterprise-Subscription. Was die Subscription tatsächlich enthält, steht in Nextcloud Hub gegen Nextcloud Enterprise. Voraussetzung ist eine Instanz über HTTPS; hinter einem Reverse Proxy muss Nextcloud die Verbindung als HTTPS erkennen (overwriteprotocol in der config.php), sonst baut die App die Redirect-URI mit http:// und Authentik lehnt sie ab.

Bei einer Docker-Installation wie in Nextcloud mit Docker, TLS und Backups auf dem VPS installieren Sie die App aus dem Verzeichnis mit der docker-compose.yml. app ist der Name des Nextcloud-Dienstes aus Ihrer Compose-Datei:

docker compose exec -u www-data app php occ app:install user_oidc

Danach erscheint in den Verwaltungseinstellungen der Abschnitt OpenID Connect. Mit Register new provider legen Sie den Eintrag an:

• Identifier: authentik (frei wählbar, erscheint auf dem Login-Button)
• Client ID und Client secret aus Authentik
• Discovery endpoint: https://auth.example.com/application/o/nextcloud/.well-known/openid-configuration
• Scope: openid email profile

Redirect-URI in Authentik: https://cloud.example.com/apps/user_oidc/code. Als Post-Logout-Redirect können Sie https://cloud.example.com eintragen, dann landet der Nutzer nach dem Abmelden wieder auf der Login-Seite.

Wer die App lieber ohne Klicken einrichtet, nutzt denselben Befehl mit Parametern:

docker compose exec -u www-data app php occ user_oidc:provider authentik \
  --clientid="<Client ID>" \
  --clientsecret="<Client Secret>" \
  --discoveryuri="https://auth.example.com/application/o/nextcloud/.well-known/openid-configuration"

Die Option, die Sie vor dem ersten Login verstehen müssen, heißt Use unique user id. Sie ist standardmäßig an. Dann bildet die App die Nextcloud-Benutzerkennung als Hash aus Provider-ID und Subject. Das verhindert Kollisionen zwischen mehreren Providern, hat aber eine Folge: Ein bestehender Nutzer anna bekommt beim ersten SSO-Login ein zweites, leeres Konto mit einer kryptischen Kennung. Ihre Dateien liegen weiter bei anna, nur ist sie dort nicht mehr angemeldet.

Wenn bestehende Konten weiterleben sollen, schalten Sie die Option ab und setzen im Abschnitt Attribute mapping die Zuordnung für die User ID auf preferred_username. Authentik schickt darin den Benutzernamen aus dem Scope profile. Stimmt der Authentik-Benutzername mit dem Nextcloud-Benutzernamen überein, landet anna in ihrem alten Konto. Prüfen Sie das mit einem Testkonto, bevor Sie echte Nutzer umstellen.

Gruppen übernimmt die App, wenn Group provisioning aktiv ist und die Zuordnung für Gruppen auf groups steht. Eine Authentik-Gruppe namens admin macht den Nutzer zum Nextcloud-Administrator, also vergeben Sie diesen Namen bewusst.

Zum Abschalten des Passwort-Logins:

docker compose exec -u www-data app php occ config:app:set --type=string --value=0 user_oidc allow_multiple_user_backends

Der lokale Login bleibt danach unter https://cloud.example.com/login?direct=1 erreichbar. Merken Sie sich diese Adresse, sie ist Ihr Weg zurück, wenn Authentik einmal nicht antwortet.

Grafana: Generic OAuth in der freien Ausgabe

Grafana nennt den OIDC-Login Generic OAuth. Er ist in der Open-Source-Ausgabe enthalten, ebenso die Zuordnung von Rollen über role_attribute_path. Hinter der Bezahlschranke liegt Team Sync, also das automatische Füllen von Grafana-Teams aus einem Gruppen-Claim: Die Dokumentation führt es als „Available in Grafana Enterprise and Grafana Cloud“. Rollen pro Nutzer reichen für die meisten Installationen aus.

Redirect-URI in Authentik: https://grafana.example.com/login/generic_oauth. Grafana baut diese Adresse aus root_url. Steht dort noch der Standardwert http://localhost:3000/, schickt Grafana genau diese Adresse an Authentik, und der Login endet auf der Fehlerseite. Setzen Sie GF_SERVER_ROOT_URL deshalb zuerst.

services:
  grafana:
    image: grafana/grafana-oss:latest
    environment:
      GF_SERVER_ROOT_URL: "https://grafana.example.com"
      GF_AUTH_GENERIC_OAUTH_ENABLED: "true"
      GF_AUTH_GENERIC_OAUTH_NAME: "Authentik"
      GF_AUTH_GENERIC_OAUTH_CLIENT_ID: "<Client ID>"
      GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET: "<Client Secret>"
      GF_AUTH_GENERIC_OAUTH_SCOPES: "openid email profile"
      GF_AUTH_GENERIC_OAUTH_AUTH_URL: "https://auth.example.com/application/o/authorize/"
      GF_AUTH_GENERIC_OAUTH_TOKEN_URL: "https://auth.example.com/application/o/token/"
      GF_AUTH_GENERIC_OAUTH_API_URL: "https://auth.example.com/application/o/userinfo/"
      GF_AUTH_GENERIC_OAUTH_ALLOW_SIGN_UP: "true"
      GF_AUTH_GENERIC_OAUTH_ROLE_ATTRIBUTE_PATH: "contains(groups[*], 'grafana-admins') && 'Admin' || contains(groups[*], 'grafana-editors') && 'Editor' || 'Viewer'"
      GF_AUTH_SIGNOUT_REDIRECT_URL: "https://auth.example.com/application/o/grafana/end-session/"

Jede Variable entspricht einem Schlüssel im Abschnitt [auth.generic_oauth] der grafana.ini, das Muster ist GF_AUTH_GENERIC_OAUTH_<SCHLÜSSEL>. Der Ausdruck in ROLE_ATTRIBUTE_PATH ist JMESPath: Er liest den Claim groups aus der Userinfo-Antwort und gibt die erste passende Rolle zurück, sonst Viewer. Die Gruppennamen müssen genau so in Authentik existieren. Wer Server-Administrator werden soll, braucht zusätzlich GF_AUTH_GENERIC_OAUTH_ALLOW_ASSIGN_GRAFANA_ADMIN=true und GrafanaAdmin im Ausdruck; sonst vergibt Grafana höchstens die Organisationsrolle Admin.

SIGNOUT_REDIRECT_URL sorgt dafür, dass ein Klick auf Abmelden auch die Authentik-Sitzung beendet. Ohne die Zeile meldet Grafana nur sich selbst ab, und der nächste Klick auf den Login-Button meldet den Nutzer ohne Passwortabfrage wieder an, weil die Sitzung bei Authentik noch besteht.

Paperless-ngx: OIDC über django-allauth

Paperless-ngx nutzt die Bibliothek django-allauth und wird über Umgebungsvariablen konfiguriert, typischerweise in der docker-compose.env. Die Provider-Konfiguration ist ein JSON-Dokument in einer einzigen Variable:

PAPERLESS_URL=https://dms.example.com
PAPERLESS_APPS=allauth.socialaccount.providers.openid_connect
PAPERLESS_SOCIALACCOUNT_PROVIDERS='{"openid_connect": {"APPS": [{"provider_id": "authentik", "name": "Authentik", "client_id": "<Client ID>", "secret": "<Client Secret>", "settings": {"server_url": "https://auth.example.com/application/o/paperless/.well-known/openid-configuration"}}]}}'
PAPERLESS_SOCIAL_AUTO_SIGNUP=true
PAPERLESS_SOCIALACCOUNT_ALLOW_SIGNUPS=true
PAPERLESS_DISABLE_REGULAR_LOGIN=false
PAPERLESS_REDIRECT_LOGIN_TO_SSO=false

Die Redirect-URI enthält die provider_id aus dem JSON: https://dms.example.com/accounts/oidc/authentik/login/callback/. Ändern Sie die provider_id, ändert sich die URI, und der Schrägstrich am Ende gehört dazu. PAPERLESS_SOCIAL_AUTO_SIGNUP=true legt beim ersten Login ein Konto mit E-Mail und Benutzername aus dem Token an; ohne die Variable zeigt django-allauth zuerst ein Formular zum Anlegen des Kontos.

Gruppen aus Authentik übernimmt Paperless mit PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS=true, aber nur, wenn das JSON im Objekt openid_connect zusätzlich "SCOPE": ["openid", "profile", "email", "groups"] enthält. Die Gruppen müssen in Paperless-ngx bereits existieren und genauso heißen wie in Authentik. Authentik kennt keinen eigenen Scope groups und lässt ihn weg; der Claim kommt trotzdem an, weil er Teil des Scopes profile ist. Kosten: keine, Paperless-ngx hat keine Bezahlstufe.

Die zwei Fehler, die jeder einmal sieht

Redirect URI Error

Authentik zeigt statt der Anmeldeseite die Meldung Redirect URI Error mit dem Text The request fails due to a missing, invalid, or mismatching redirection URI (redirect_uri). Die Ursache steht unter Events > Logs als Ereignis vom Typ Configuration error:

Invalid redirect URI was used. Client used 'http://localhost:3000/login/generic_oauth'. Allowed redirect URIs are https://grafana.example.com/login/generic_oauth

Die Meldung nennt beide Werte, und der Vergleich zeigt sofort, was fehlt. Im Modus Strict zählt jedes Zeichen. Die vier Varianten, die immer wieder auftauchen: http statt https, weil die App hinter dem Proxy nicht weiß, dass sie über TLS erreichbar ist (bei Grafana root_url, bei Nextcloud overwriteprotocol); ein fehlender oder überzähliger Schrägstrich am Ende (Paperless-ngx braucht ihn, Grafana nicht); ein Port in der URI, der in Authentik fehlt; und bei Paperless-ngx eine provider_id, die nicht zur eingetragenen URI passt. Kopieren Sie den Wert hinter Client used in den Provider, wenn er inhaltlich richtig ist, sonst korrigieren Sie die App.

Das Access-Token lebt nur fünf Minuten

Authentik setzt Access token validity bei einem neuen Provider auf minutes=5. Für die meisten Apps ist das egal, weil sie nach dem Login eine eigene Sitzung führen. Vaultwarden ist die Ausnahme: Der Bitwarden-Web-Vault prüft die Restlaufzeit des Tokens und behandelt ein Token, das in unter fünf Minuten abläuft, als abgelaufen. Mit dem Standardwert ist das sofort nach dem Login der Fall. Das Wiki formuliert es so: „Default access token lifetime might be only 5min, set a longer value otherwise it will collide with Bitwarden front-end expiration detection which is also set at 5min.“ Die Folge ist eine Anmeldung, die scheinbar klappt und Sekunden später wieder auf der Login-Seite landet. Setzen Sie den Wert im Provider auf hours=1 und lassen Sie Refresh token validity auf dem Standard days=30.

Apps ohne OIDC: Forward Auth statt Umbau

Nicht jede App kann OIDC. Ein Dashboard, ein kleiner Dienst mit Basic Auth oder ein Tool ohne jedes Login lassen sich trotzdem hinter Authentik legen. Dafür fragt der Reverse Proxy vor jeder Anfrage bei Authentik nach, ob der Browser eine gültige Sitzung hat, und leitet sonst zur Anmeldung um. Die App selbst merkt davon nichts. Dieses Muster heißt Forward Auth. Die Einrichtung mit Traefik steht in Forward Auth mit Authentik und Traefik. Wer statt Traefik nginx oder Caddy nutzt oder Authentik gar nicht als Proxy-Provider betreiben will, kommt mit oauth2-proxy vor beliebigen Apps ans selbe Ziel.

Forward Auth hat eine Grenze: Die App weiß nicht, wer angemeldet ist, außer sie liest Header wie X-authentik-username aus. Rollen, Gruppen und getrennte Benutzerdaten gibt es nur mit echtem OIDC. Deshalb lohnt sich der Aufwand aus dieser Anleitung für Apps, die Konten führen.

Reihenfolge für den Umstieg

Stellen Sie eine App nach der anderen um und halten Sie dabei immer einen Passwort-Login offen. Der Ablauf, der sich bewährt hat:

1. Provider und Application anlegen, Redirect-URI eintragen, Gruppe binden.
2. App konfigurieren und neu starten.
3. Im privaten Browserfenster per SSO anmelden, während die Admin-Sitzung im anderen Fenster offen bleibt.
4. Prüfen, ob der Nutzer im richtigen Konto gelandet ist und die erwarteten Rechte hat.
5. Erst dann den Passwort-Login abschalten: SSO_ONLY=true bei Vaultwarden, allow_multiple_user_backends bei Nextcloud, PAPERLESS_DISABLE_REGULAR_LOGIN=true bei Paperless-ngx.

Auch danach brauchen Sie einen Notausgang für den Tag, an dem Authentik nicht startet. Bei Nextcloud ist es ?direct=1, bei Vaultwarden bleibt die Admin-Seite über ADMIN_TOKEN erreichbar, bei Grafana bleibt das Passwort des lokalen Admin-Kontos gültig, solange Sie GF_AUTH_DISABLE_LOGIN_FORM nicht setzen. Schreiben Sie diese Wege auf, bevor Sie sie brauchen.

FAQ

Brauche ich in Authentik für jede App einen eigenen Provider?

Ja. Ein Provider hat genau einen Satz Redirect-URIs und ein Client-Secret, und der Slug der Application bildet die Issuer-URL. Zwei Apps auf einem Provider würden sich Secret und erlaubte Rücksprungadressen teilen, und eine kompromittierte App könnte Tokens für die andere einlösen. Ein Paar aus Provider und Application pro App ist der Normalfall, auch wenn dann zehn Einträge in der Liste stehen.

Warum landet ein Nextcloud-Nutzer nach dem SSO-Login in einem leeren Konto?

Weil die Option Use unique user id in user_oidc eingeschaltet ist. Die App bildet dann die Benutzerkennung als Hash aus Provider-ID und Subject, und dieser Hash ist ein neues Konto ohne Dateien. Schalten Sie die Option ab und setzen Sie die User-ID-Zuordnung auf preferred_username; wenn der Authentik-Benutzername dem Nextcloud-Benutzernamen entspricht, landet der Nutzer wieder in seinem alten Konto.

Ist SSO für Vaultwarden wirklich kostenlos?

Ja. Vaultwarden enthält den OIDC-Login seit Version 1.35.0 ohne Lizenz und ohne Organisationspflicht. Bitwarden selbst bietet „Login mit SSO“ (Stand September 2026) nur im Enterprise-Plan an. Das Master-Passwort bleibt auch mit SSO nötig, weil daraus der Schlüssel für den Tresor abgeleitet wird und Authentik diesen Schlüssel nie sieht.

Warum wirft Vaultwarden mich kurz nach dem SSO-Login wieder raus?

Weil das Access-Token von Authentik nur fünf Minuten gültig ist und der Bitwarden-Web-Vault ein Token mit weniger als fünf Minuten Restlaufzeit als abgelaufen behandelt. Setzen Sie im Authentik-Provider Access token validity auf hours=1 und wählen Sie den Scope offline_access, damit Vaultwarden ein Refresh-Token bekommt.

Was mache ich mit einer App, die kein OIDC kann?

Legen Sie sie hinter Forward Auth. Der Reverse Proxy fragt vor jeder Anfrage bei Authentik nach einer gültigen Sitzung und leitet sonst zur Anmeldung um; die App selbst bleibt unverändert. Rollen und getrennte Benutzerkonten bekommen Sie damit nicht, aber der Zugang ist geschützt.