Auth0 · OIDC · RBAC
Anmeldung zur Factory
Dashboard und Dokumentation sind bewusst öffentlich lesbar. Erst eine Steuerungsaktion startet die Auth0-Anmeldung.
Die Factory hat eine eigene Auth0-API mit RS256 und RBAC. Die Rolle
factory:operator gibt die standardisierte API-Berechtigung factory:control; der Worker akzeptiert kein Browser- oder GitHub-Secret.Ablauf
sequenceDiagram
participant B as Browser
participant D as Dashboard steering
participant A as Auth0 Universal Login
participant P as enrolled passkey
participant F as Factory Control API
Note over B,D: Public pages: no login
B->>D: Start control action
D->>A: Authorization Code + PKCE
audience=factory-control A->>P: WebAuthn challenge when a passkey is enrolled P-->>A: Signed assertion A-->>D: Authorization code D->>A: Exchange code + PKCE verifier A-->>D: RS256 access token
permissions: factory:control D->>F: Mutation + Bearer token F->>A: Verify signature via JWKS F-->>D: Allowed or denied response
audience=factory-control A->>P: WebAuthn challenge when a passkey is enrolled P-->>A: Signed assertion A-->>D: Authorization code D->>A: Exchange code + PKCE verifier A-->>D: RS256 access token
permissions: factory:control D->>F: Mutation + Bearer token F->>A: Verify signature via JWKS F-->>D: Allowed or denied response
Sicherheitsgrenzen
Die SPA-Client-ID und die API-Audience sind öffentlich, ein Client Secret ist es nicht. GitHub- und Cloudflare-Credentials liegen ausschließlich serverseitig. Passkeys sind der bevorzugte Faktor, sobald sie in Auth0 für das Benutzerkonto eingerichtet sind; ein Passwort-Fallback bleibt eine bewusste Tenant-Entscheidung.
Source of truth: docs/arc42/08-factory-auth0-setup.md