updated the docs, removed oauth and introduced sanctum pat

docs/prp/tenant-app-specs/README.md

@@ -16,12 +16,12 @@ Die App ersetzt das frühere Filament-basierte Tenant-Panel und fokussiert auf e
 - **Direkter Checkout**: Paddle sind in die Paketwahl des Welcome Flows eingebettet; Fortschritt wird im Onboarding-Context persistiert.
 - **Filament Wizard**: Für Super-Admins existiert ein paralleler QR/Join-Token-Wizard in Filament (Token-Generierung, Layout-Downloads, Rotation).
 - **Join Tokens only**: Gäste erhalten ausschließlich join-token-basierte Links/QRs; slug-basierte URLs wurden deaktiviert. QR-Drucklayouts liegen unter `resources/views/pdf/join-tokens/*`.
-- **OAuth Alignment**: `VITE_OAUTH_CLIENT_ID` + `/event-admin/auth/callback` werden seedingseitig synchron gehalten; siehe `docs/prp/tenant-app-specs/api-usage.md`.
+- **Auth Alignment**: Sanctum-PATs über `/api/v1/tenant-auth/login` + `/tenant-auth/exchange`; siehe `docs/prp/tenant-app-specs/api-usage.md`.
 
 ## Kernziele
 - **Deliverables**: Voll funktionsfähige App mit CRUD-Operationen für Tenant-Ressourcen (Events, Photos, Tasks, etc.).
 - **UI/UX**: Framework7-Komponenten für konsistente, native Mobile-Interfaces (iOS/Android).
-- **Technologie-Stack**: React/Vite (Core), Framework7 (UI), Capacitor (Native), OAuth2 + PKCE (Auth).
+- **Technologie-Stack**: React/Vite (Core), Framework7 (UI), Capacitor (Native), Sanctum PATs (Auth).
 - **Distribution**: App Store (iOS), Google Play (Android), PWA-Install (Web).
 
 ## Struktur dieser PRP

docs/prp/tenant-app-specs/api-usage.md

@@ -1,28 +1,30 @@
 # API-Nutzung der Tenant Admin App
 
-Diese Dokumentation beschreibt alle API-Endpunkte, die die Tenant Admin App mit der Backend-Hauptapp kommuniziert. Alle Requests sind tenant-scoped und erfordern JWT-Authentifizierung.
+Diese Dokumentation beschreibt alle API-Endpunkte der Tenant Admin App. Alle Requests sind tenant-scoped und erfordern ein Sanctum Personal Access Token (PAT) mit der Fähigkeit `tenant-admin` bzw. `tenant:<id>`.
 
 ## Authentifizierung
 
-### OAuth2 Flow (PKCE)
-- **Start**: `GET /oauth/authorize` (Browser-Redirect mit PKCE-Challenge)
-  - **Params**: `client_id`, `redirect_uri`, `scope=tenant:read tenant:write`, `state`, `code_challenge`, `code_challenge_method=S256`
-  - **Response**: Authorization Code
+### Passwort-Login (PAT)
+- **Endpoint**: `POST /api/v1/tenant-auth/login`
+- **Body** (`application/json`): `{ "login": "username oder email", "password": "••••" }`
+- **Response**: `{ token, token_type, abilities[], user { ... } }`
+- **Fehler**: `422` bei ungültigen Daten, `429` bei Rate-Limit (`throttle:tenant-auth`).
+- **Hinweis**: `login` akzeptiert E-Mail _oder_ Usernamen. Erfolgreiche Logins revoken vorhandene PATs mit Name `tenant-admin`.
 
-- **Token Exchange**: `POST /oauth/token`
-  - **Body**: `grant_type=authorization_code`, `client_id`, `code`, `redirect_uri`, `code_verifier`
-  - **Response**: `{ access_token, refresh_token, expires_in, token_type }`
-  - **Headers**: `Content-Type: application/x-www-form-urlencoded`
+### Session→PAT Exchange (Google/Login-Shell)
+- **Endpoint**: `POST /api/v1/tenant-auth/exchange`
+- **Middleware**: Sanctum stateful cookies (`SANCTUM_STATEFUL_DOMAINS`), `throttle:tenant-auth`.
+- **Use-Case**: Nach Google-Login oder Marketing-Checkout Session wird das PAT ohne erneute Passwort-Eingabe ausgegeben.
+- **Response**: identisch zum Passwort-Login.
 
-- **Token Refresh**: `POST /oauth/token`
-  - **Body**: `grant_type=refresh_token`, `client_id`, `refresh_token`
-  - **Response**: Neuer Access/Refresh-Token
+### Token Status & Logout
+- **`GET /api/v1/tenant-auth/me`** – liefert `{ user, tenant, abilities }` und spiegelt die PAT-Fähigkeiten wider.
+- **`POST /api/v1/tenant-auth/logout`** – löscht das aktuelle PAT aus `personal_access_tokens`.
 
-- **Token Validation**: `GET /api/v1/tenant/me`
-  - **Redirect URI**: Standardmaessig `${origin}/event-admin/auth/callback` (per Vite-Env anpassbar)
-  - **Headers**: `Authorization: Bearer {access_token}`
-  - **Response**: `{ id, email, tenant_id, role, name }`
-  - **Hinweis**: `client_id` entspricht `VITE_OAUTH_CLIENT_ID`; Seeder `OAuthClientSeeder` synchronisiert Frontend und Backend.
+### Legacy Payload `/tenant/me`
+- **Endpoint**: `GET /api/v1/tenant/me`
+- **Response**: historisches Format (`tenant_id`, `remaining_events`, `scopes`), betrieben über denselben PAT.
+- **Kompatibilität**: Dient älteren Clients als Übergang; neue Features sollten `/tenant-auth/me` verwenden.
 
 ## Dashboard
 
@@ -188,7 +190,7 @@ Diese Dokumentation beschreibt alle API-Endpunkte, die die Tenant Admin App mit
 ## Allgemeine Headers
 
 Alle API-Requests enthalten:
-- **Authorization**: `Bearer {access_token}` (JWT mit tenant_id)
+- **Authorization**: `Bearer {access_token}` (Sanctum PAT mit Fähigkeit `tenant:{id}`)
 - **Content-Type**: `application/json` (für POST/PATCH)
 - **If-Match**: `{etag}` (für Concurrency-Control bei Updates)
 - **Accept**: `application/json`
@@ -230,7 +232,7 @@ Mutierende Endpunkte (PATCH/DELETE) erfordern:
 
 ## Sicherheit
 
-- **Tenant-Isolation**: Alle Endpunkte prüfen JWT-tenant_id gegen request tenant_id
+- **Tenant-Isolation**: Middleware vergleicht PAT-Fähigkeit (`tenant:{id}`) mit dem angefragten Tenant
 - **RBAC**: Nur tenant_admin kann mutieren, member kann nur lesen/hochladen
 - **Rate Limiting**: 100 Requests/Minute pro Tenant
 - **ETag**: Automatische Concurrency-Control
@@ -259,8 +261,9 @@ curl -H "Authorization: Bearer {token}" \
 
 ### Environment-Variablen
 - **VITE_API_URL**: Backend-API-URL (Pflicht)
-- **VITE_OAUTH_CLIENT_ID**: OAuth-Client-ID (Pflicht, muss mit `config/services.php` übereinstimmen – der Seeder legt damit den Client in `oauth_clients` an)
-- **VITE_REVENUECAT_PUBLIC_KEY**: Optional fuer In-App-Kaeufe (RevenueCat)
+- **VITE_ENABLE_TENANT_SWITCHER**: Dev-Flag um Tenants im Header auszuwählen (optional, Default `false`)
+- **VITE_REVENUECAT_PUBLIC_KEY**: Optional für In-App-Käufe (RevenueCat)
+- **SANCTUM_STATEFUL_DOMAINS** (Backend): Enthält die Origins des Admin-PWA/TWA, damit der Session→PAT-Exchange funktioniert.
 - **REVENUECAT_WEBHOOK_SECRET / REVENUECAT_PRODUCT_MAPPINGS / REVENUECAT_APP_USER_PREFIX / REVENUECAT_WEBHOOK_QUEUE**: Backend-Konfiguration für RevenueCat-Webhooks, siehe `config/services.php`.
 
 ### Build & Deploy
@@ -273,4 +276,3 @@ curl -H "Authorization: Bearer {token}" \
 - Installierbar auf Desktop/Mobile via "Zum Startbildschirm hinzufügen".
 
 Für weitere Details siehe die spezifischen Dokumentationsdateien.
-

docs/prp/tenant-app-specs/functional-specs.md

@@ -18,8 +18,8 @@ Die Admin-App muss folgende Kernfunktionen bereitstellen:
 
 ## Capabilities
 ### Authentifizierung & Autorisierung
-- OAuth2 Authorization Code mit PKCE, Refresh-Tokens via Secure Storage (Web: IndexedDB, Capacitor: Preferences/Keychain).
-- Tenant-Scoped Tokens; Rollen `tenant_admin` (vollständig) & `member` (read-only, Upload).
+- Sanctum Personal Access Tokens (`/api/v1/tenant-auth/login|exchange`) mit Fähigkeiten `tenant-admin`, `tenant:{id}`; Speicherung in IndexedDB sowie Keychain/Keystore für Capacitor.
+- Rollenbasierte Fähigkeiten: `tenant_admin` (vollständig), `member` (read-only, Upload). Token-Exchange nach Google-Login oder Session-Login via `/tenant-auth/exchange`.
 
 ### Onboarding Journey
 - Routen `/event-admin/welcome/*` bilden den Flow.
@@ -67,7 +67,7 @@ Die App nutzt Endpunkte aus `docs/prp/03-api.md`.
 
 | Bereich | Endpunkte |
 | --- | --- |
-| Auth | `POST /oauth/token`, `POST /oauth/token/refresh` |
+| Auth | `POST /tenant-auth/login`, `POST /tenant-auth/exchange`, `POST /tenant-auth/logout` |
 | Onboarding | `GET /tenant/me` (Progress Flags), `GET /tenant/packages`, `POST /tenant/events` |
 | Events | `GET/POST/PATCH/DELETE /tenant/events`, `POST /tenant/events/{event}/toggle`, Join-Token Routen |
 | Medien | `GET /tenant/events/{event}/photos`, `POST /tenant/events/{event}/photos`, `PATCH /tenant/photos/{id}` |
@@ -76,7 +76,7 @@ Die App nutzt Endpunkte aus `docs/prp/03-api.md`.
 
 ## Nicht-funktionale Anforderungen
 - **Performance**: Ladezeit < 2s; Code-Splitting der Onboarding-Screens.
-- **Sicherheit**: Keine sensiblen Logs; CSRF-mitigiert via PKCE/OAuth; Token-Refresh automatisiert.
+- **Sicherheit**: Keine sensiblen Logs; CSRF abgesichert via Sanctum stateful middleware; Token-Neuausstellung durch erneutes Login oder Exchange.
 - **Accessibility**: Tastaturbedienung, Fokus-Indikatoren, `prefers-reduced-motion`.
 - **Internationalisierung**: Sprachumschaltung in Einstellungen; Standard de, Fallback en.