Skip to main content

Integrazione con Supabase Auth

Switchbord utilizza Supabase Auth come spina dorsale dell’autenticazione. Tutte le sessioni utente sono gestite tramite il sistema di sessione basato su JWT di Supabase, con validazione lato server a ogni richiesta API.
L’autenticazione è applicata a livello di route API. Ogni route inizia con la validazione della sessione prima che venga eseguita qualsiasi logica di business.

Gestione delle Sessioni

Timebox delle Sessioni

Le sessioni sono soggette a due controlli di scadenza indipendenti: Questi limiti sono configurati in Supabase e applicati lato server — estenderli richiede una modifica della configurazione da parte di un admin, non un workaround lato client.

Revoca della Sessione alla Rimozione di un Membro

Quando un membro del workspace viene rimosso, le sue sessioni attive vengono immediatamente invalidate su tutti i dispositivi:
L’ambito 'global' garantisce che tutte le sessioni dell’utente vengano terminate — non solo quella corrente. Ciò impedisce a un membro rimosso di continuare a utilizzare una sessione esistente dopo aver perso l’accesso al workspace.

Politica delle Password

Switchbord applica i seguenti requisiti per le password, configurati in Supabase:
  • Minimo 12 caratteri
  • Almeno una lettera maiuscola
  • Almeno una cifra
  • Applicata alla registrazione e al cambio password
Si incoraggia gli utenti a utilizzare un password manager e a generare password univoche per ogni servizio.

Autenticazione Multi-Fattore

L’MFA TOTP (Time-based One-Time Password) di Supabase è disponibile per tutti gli utenti. Gli utenti possono registrare un’app di autenticazione dalle impostazioni del proprio account.
L’applicazione obbligatoria dell’MFA (richiedere l’MFA per tutti i membri del workspace) è attualmente pianificata e tracciata nella roadmap. Finché l’applicazione obbligatoria non sarà implementata, l’MFA è opzionale per singolo utente. Le organizzazioni con requisiti di conformità rigorosi dovrebbero istruire i propri membri a registrarsi.

Controllo degli Accessi Basato sui Ruoli

Switchbord implementa quattro ruoli con livelli di permesso distinti. L’assegnazione dei ruoli è gestita dagli owner e dagli admin del workspace.

Gerarchia dei Ruoli

Applicazione dei Ruoli

I controlli sui ruoli vengono eseguiti a ogni route API dopo la risoluzione del contesto del workspace:
L’elenco dei ruoli passato a requireSettingsAccess definisce i ruoli minimi richiesti. Le route non presenti nell’elenco riceveranno una risposta 403.

Riferimento delle Capacità per Ruolo

Gestione delle API Key

Ciclo di Vita delle Chiavi

Le API key consentono l’accesso programmatico all’API di Switchbord. Ogni chiave viene:
  1. Generata con un valore crittograficamente casuale
  2. Sottoposta a hashing con SHA-256 prima della memorizzazione — il testo in chiaro viene mostrato una sola volta al momento della creazione
  3. Ambita al workspace che la crea — non può essere utilizzata per accedere ad altri workspace
  4. Opzionalmente scadutaexpires_at viene applicato al momento della validazione

Confronto Timing-Safe

La validazione delle API key utilizza crypto.timingSafeEqual per prevenire attacchi timing side-channel:

Applicazione della Scadenza delle Chiavi

Le chiavi con un valore expires_at vengono rifiutate al momento della validazione, anche se l’hash corrisponde:

Operazioni sulle Chiavi con Ambito Workspace

Tutte le operazioni sulle chiavi (elenco, eliminazione, revoca) sono filtrate in base al workspace risolto del chiamante:

Mappatura della Conformità

Per la mappatura completa dei controlli di conformità, vedi la Matrice di Conformità.