App-Client darf eine eigene Anwendung beim Anmeldedienst sein

In Authentik hat jede Anwendung standardmaessig ihren eigenen Issuer, abgeleitet
aus dem Application-Slug. Web- und App-Client brauchen dort aber zwei getrennte
Anwendungen, weil ein Provider entweder vertraulich ODER oeffentlich ist.

Bisher wurde das App-Token gegen den Issuer und den Schluesselsatz der
Web-Anwendung geprueft - die App-Anmeldung waere damit an der iss-Pruefung
gescheitert. Discovery und JWKS werden jetzt je Adresse gepuffert statt je
Anbieter, und OIDC_<KUERZEL>_NATIVE_DISCOVERY_URL benennt die Anwendung des
App-Clients. Ohne die Variable bleibt es bei einer gemeinsamen Adresse.

Ausserdem im README: der Signing Key muss gesetzt sein, sonst signiert Authentik
mit HS256 und das Token wird abgelehnt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -105,20 +105,28 @@ Neben dem Passwort-Login kann sich Vorrania an einen OpenID-Connect-Dienst
 hängen (getestet mit Authentik). Ohne Konfiguration ändert sich nichts: Es gibt
 keinen SSO-Knopf, und der Passwort-Login bleibt der einzige Weg.
 
-**1. In Authentik zwei Provider anlegen** – die Web-Oberfläche und die App
-brauchen unterschiedliche Client-Typen:
+**1. In Authentik zwei Anwendungen anlegen** – Web-UI und App brauchen
+unterschiedliche Client-Typen, und ein Provider kann nur einer davon sein:
 
-| Für | Typ | Redirect-URI |
-|-----|-----|--------------|
+| Für | Client-Typ | Redirect-URI |
+|-----|-----------|--------------|
 | Web-UI | *Confidential* (mit Secret) | `https://<deine-adresse>/api/auth/oidc/authentik/callback` |
 | iOS-App | *Public* (ohne Secret, PKCE) | `vorrania://oauth/callback` |
 
-Das `/api` in der Web-Adresse ist kein Versehen: Es entsteht im mitgelieferten
-nginx und gehört deshalb in die bei Authentik hinterlegte Adresse.
+Drei Punkte, an denen es sonst klemmt:
 
-Damit die App ihre Anmeldung im Hintergrund erneuern kann, muss der
-öffentliche Client `offline_access` ausliefern dürfen (in Authentik seit 2024.2
-ein eigenes Scope-Mapping) – sonst kommt kein Refresh-Token zurück.
+- Das `/api` in der Web-Adresse ist kein Versehen: Es entsteht im mitgelieferten
+  nginx und gehört deshalb in die bei Authentik hinterlegte Adresse.
+- **Signing Key setzen** (Provider ▸ *Advanced protocol settings*). Ohne ihn
+  signiert Authentik mit HS256, und Vorrania prüft gegen den öffentlichen
+  Schlüsselsatz – das Token würde abgelehnt.
+- Jede Anwendung hat in Authentik **ihren eigenen Issuer** (aus dem
+  Application-Slug). Deshalb bekommt der App-Client eine eigene
+  Discovery-Adresse: `OIDC_AUTHENTIK_NATIVE_DISCOVERY_URL`.
+
+Damit die App ihre Anmeldung im Hintergrund erneuern kann, muss der öffentliche
+Client `offline_access` ausliefern dürfen (in Authentik seit 2024.2 ein eigenes
+Scope-Mapping) – sonst kommt kein Refresh-Token zurück.
 
 **2. `deploy/.env` ergänzen** (vollständige Vorlage in `deploy/.env.example`):
 
@@ -130,6 +138,7 @@ OIDC_AUTHENTIK_DISCOVERY_URL=https://authentik.example.com/application/o/vorrani
 OIDC_AUTHENTIK_CLIENT_ID=...
 OIDC_AUTHENTIK_CLIENT_SECRET=...
 OIDC_AUTHENTIK_NATIVE_CLIENT_IDS=vorrania-ios
+OIDC_AUTHENTIK_NATIVE_DISCOVERY_URL=https://authentik.example.com/application/o/vorrania-ios/.well-known/openid-configuration
 ```
 
 Danach `./update.sh` (oder `docker compose --env-file .env up -d`).