Auth & SSO

FireFeed delega l'autenticazione a un Keycloak 26 remoto, integrato via NextAuth v5 (beta).

Perché Keycloak

• Multi-client SSO: lo stesso Keycloak serve FireFeed e altre applicazioni del gruppo Connecteed — un solo login per più prodotti.
• Identity Provider federation: supporto out-of-the-box per Google, Microsoft Entra ID, SAML enterprise; pronti per onboarding clienti che vogliono il proprio IdP.
• Roles & groups gestiti centralmente — la membership in una company FireFeed è derivata da un claim Keycloak.

Flow di login

1. Browser → /signin            (FireFeed)
2. NextAuth redirect           → Keycloak /realms/connecteed/protocol/openid-connect/auth
3. Utente login                (Keycloak hosted UI)
4. Keycloak redirect           → FireFeed /api/auth/callback/keycloak con authorization code
5. NextAuth scambia code       → access_token + id_token + refresh_token
6. Adapter Prisma upserta      → users + accounts + sessions
7. Browser → cookie session    → home FireFeed

Codice rilevante

• packages/auth/ — provider config + Prisma adapter wrapper
• packages/web/lib/auth.ts — auth() helper
• packages/web/lib/api-utils.ts — getSessionOrThrow(), getActiveCompany()
• packages/web/app/api/auth/[...nextauth]/route.ts — handler NextAuth

Variabili ambiente

AUTH_SECRET=...
AUTH_KEYCLOAK_ID=firefeed-experimental
AUTH_KEYCLOAK_SECRET=...
AUTH_KEYCLOAK_ISSUER=https://keycloak.connecteed.dev/realms/connecteed
AUTH_TRUST_HOST=true              # behind reverse proxy

Migrazione storica

Originariamente FireFeed usava Better Auth. La migrazione a NextAuth v5 + Keycloak è stata fatta per abilitare SSO multi-client. Dettagli: vedi memo project_auth_migration nelle note di sviluppo.

Sessione nel codice

Ogni route handler protetto chiama getSessionOrThrow() che restituisce { user, activeCompanyId } (la company attiva è scelta dall'utente in UI e persistita su un cookie). Da lì si deriva la tenancy del resto della richiesta.