Single Sign-on für WordPress mit Authentik

Ich nutze Authentik als zentrale Anmeldung für meine selbst gehosteten Dienste. Dieser Blog soll genauso funktionieren: ein Klick auf den Login-Button, Passkey, fertig. Die normale WordPress-Anmeldung bleibt als Rückfallebene erhalten, falls Authentik einmal nicht erreichbar ist.

In den Beispielen läuft Authentik unter https://auth.example.com, der Blog unter https://blog.example.com, und der Slug der Authentik-Anwendung ist blog. Ersetze diese Werte durch deine eigenen.

So funktioniert die Anmeldung

1. Du klickst auf der WordPress-Anmeldeseite auf den Login-Button.
2. WordPress leitet dich zu Authentik weiter, wo du dich anmeldest, zum Beispiel mit einem Passkey.
3. Authentik schickt dich mit einem Einmal-Code zurück zu WordPress.
4. WordPress tauscht den Code im Hintergrund gegen Tokens, liest Benutzername und E-Mail-Adresse und meldet dich als passenden WordPress-Benutzer an.

1. Authentik: Provider anlegen

Im Authentik-Adminbereich unter Applications → Providers → Create den Typ OAuth2/OpenID Provider wählen. Das sind meine Einstellungen:

Einstellung	Wert
Name	Provider for Blog
Authorization flow	default-provider-authorization-implicit-consent (ohne zusätzliche „Zugriff erlauben?“-Seite)
Invalidation flow	default-provider-invalidation-flow
Client type	Confidential
Client ID / Client Secret	erzeugt Authentik, beide für WordPress kopieren
Redirect URI (strict)	https://blog.example.com/wp-admin/admin-ajax.php?action=openid-connect-authorize
Signing key	authentik Self-signed Certificate
Scopes	die Standard-Mappings für openid, email und profile
Subject mode	Based on the User’s hashed ID
Include claims in id_token	an
Issuer mode	Each provider has a different issuer
Grant types	Authorization code und Refresh token
Access token validity	5 Minuten
Refresh token validity	30 Tage

Zum Vergleich derselbe Provider, über die API angelegt:

curl -X POST https://auth.example.com/api/v3/providers/oauth2/ 
  -H "Authorization: Bearer $AUTHENTIK_TOKEN" 
  -H "Content-Type: application/json" 
  -d '{
    "name": "Provider for Blog",
    "client_type": "confidential",
    "authorization_flow": "<UUID von default-provider-authorization-implicit-consent>",
    "invalidation_flow": "<UUID von default-provider-invalidation-flow>",
    "property_mappings": ["<openid-UUID>", "<email-UUID>", "<profile-UUID>"],
    "signing_key": "<UUID des Signatur-Zertifikats>",
    "sub_mode": "hashed_user_id",
    "include_claims_in_id_token": true,
    "grant_types": ["authorization_code", "refresh_token"],
    "redirect_uris": [{
      "matching_mode": "strict",
      "url": "https://blog.example.com/wp-admin/admin-ajax.php?action=openid-connect-authorize"
    }]
  }'

2. Authentik: Anwendung anlegen

Unter Applications → Applications → Create:

Einstellung	Wert
Name	Blog
Slug	blog (wird Teil der Issuer- und JWKS-Adresse)
Provider	Provider for Blog
Launch URL	https://blog.example.com/wp-admin/

Danach die Anwendung öffnen, unter Policy / Group / User Bindings die Benutzer oder die Gruppe binden, die sich bei WordPress anmelden dürfen. Ohne Binding kann jeder Authentik-Benutzer die Anwendung nutzen.

Alle Endpunkte stehen im Discovery-Dokument der Anwendung. Ruf es einmal auf, um zu prüfen, dass alles passt:

curl -s https://auth.example.com/application/o/blog/.well-known/openid-configuration

3. WordPress: Plugin installieren

Installiere und aktiviere OpenID Connect Generic (von daggerhart) aus dem Plugin-Verzeichnis. Die Einstellungen findest du unter Einstellungen → OpenID Connect Client. Sobald das Plugin aktiv ist, zeigt die Anmeldeseite einen Button. Er funktioniert erst, wenn die Einstellungen unten gespeichert sind.

4. WordPress: alle Plugin-Einstellungen

Feld	Wert
Login Type	OpenID Connect button on login form
Client ID	aus dem Authentik-Provider
Client Secret Key	aus dem Authentik-Provider
OpenID Scope	openid email profile
Login Endpoint URL	https://auth.example.com/application/o/authorize/
Userinfo Endpoint URL	https://auth.example.com/application/o/userinfo/
Token Validation Endpoint URL	https://auth.example.com/application/o/token/
End Session Endpoint URL	https://auth.example.com/application/o/blog/end-session/
JWKS URI	https://auth.example.com/application/o/blog/jwks/
Issuer (falls deine Version danach fragt)	https://auth.example.com/application/o/blog/
ACR values	leer lassen
Identity Key	preferred_username
Disable SSL Verify	aus
HTTP Request Timeout	5
Nickname Key	preferred_username
Email Formatting	{email}
Display Name Formatting	{name}
Identify with User Name	aus
Enable Refresh Token	an
Link Existing Users	an
Create user if does not exist	aus
Redirect Back to Origin Page	an
Redirect to the login screen when session is expired	aus
Enable Logging	beim Testen an, danach aus

Nur die JWKS-URI, die End-Session-URL und der Issuer enthalten den Slug der Anwendung. Die Endpunkte für authorize, token und userinfo sind in Authentik für alle Anwendungen gleich.

Wie bestehende Benutzer zugeordnet werden

Mit Link Existing Users sucht das Plugin einen WordPress-Benutzer, dessen Benutzername dem Wert des Identity Keys entspricht, hier also dem Authentik-Benutzernamen (preferred_username). Bei der ersten Anmeldung werden die beiden Konten verknüpft, danach bleibt die Verknüpfung fest. Verwende in WordPress und Authentik denselben Benutzernamen. Solange Create user if does not exist aus ist, bekommt niemand ein neues WordPress-Konto, nur weil er einen Authentik-Zugang hat.

Optional: das Secret aus der Datenbank heraushalten

Statt die Werte auf der Einstellungsseite einzutragen, kannst du sie in der wp-config.php definieren. Das Plugin verwendet dann diese Werte und zeigt die Felder schreibgeschützt an:

define( 'OIDC_CLIENT_ID', 'deine-client-id' );
define( 'OIDC_CLIENT_SECRET', 'dein-client-secret' );
define( 'OIDC_CLIENT_SCOPE', 'openid email profile' );
define( 'OIDC_ENDPOINT_LOGIN_URL', 'https://auth.example.com/application/o/authorize/' );
define( 'OIDC_ENDPOINT_USERINFO_URL', 'https://auth.example.com/application/o/userinfo/' );
define( 'OIDC_ENDPOINT_TOKEN_URL', 'https://auth.example.com/application/o/token/' );
define( 'OIDC_ENDPOINT_LOGOUT_URL', 'https://auth.example.com/application/o/blog/end-session/' );

5. Testen

Bevor du auf den Button klickst, teste die Anfrage in der Kommandozeile. Ein funktionierender Provider leitet zum Authentik-Login weiter:

curl -s -o /dev/null -w "%{http_code} -> %{redirect_url}n" 
  "https://auth.example.com/application/o/authorize/?response_type=code&scope=openid%20email%20profile&client_id=DEINE_CLIENT_ID&state=test&redirect_uri=https%3A%2F%2Fblog.example.com%2Fwp-admin%2Fadmin-ajax.php%3Faction%3Dopenid-connect-authorize"

# gut:    302 -> https://auth.example.com/if/flow/default-authentication-flow/?...
# falsch: 302 -> https://blog.example.com/...?error=invalid_request&...

Wenn das passt: aus WordPress abmelden, auf den Login-Button klicken und mit Authentik anmelden. Du solltest als dein bestehender Benutzer im Dashboard landen.

Fehlersuche

Was du siehst	Wahrscheinliche Ursache
„The request is otherwise malformed“	Keine Grant Types im Provider (über die API angelegt)
„Redirect URI Error“	Die Redirect-URI in Authentik weicht von der ab, die WordPress sendet, schon ein Schrägstrich reicht
Zurück in WordPress, aber nicht angemeldet	Kein WordPress-Benutzer passt zu preferred_username, und das Anlegen neuer Benutzer ist aus
„Permission denied“ in Authentik	Dein Benutzer ist nicht an die Anwendung gebunden
Eine leere Seite mit „0“	Authentik hat einen Fehler an die Redirect-URI zurückgegeben. Sieh ins Authentik-Serverlog.

Was ich gelernt habe

• Die Authentik-Oberfläche setzt Standardwerte, die die API nicht setzt.
• Das Serverlog nennt den wahren Grund, wenn der Browser nur einen allgemeinen Fehler zeigt.
• Behalte die lokale WordPress-Anmeldung als Rückfallebene. Wenn der Identity Provider ausfällt, willst du trotzdem auf deine eigene Seite kommen.