Come teniamo le tue app private e separate

Ogni richiesta passa prima dall’accesso

Tutto il traffico delle app su *.teamonly.app arriva prima di tutto a un unico Worker di dispatch. Ricava organizzazione e app dall’hostname, verifica che ci sia una sessione valida e solo allora inoltra la richiesta all’app. Senza sessione, il visitatore riceve la schermata di accesso. Il codice del cliente non gira mai per lui.

Ci sono tre modi per accedere: Google OpenID Connect, Microsoft (Entra ID) OpenID Connect o un codice monouso inviato a un indirizzo email aziendale. Per Google e Microsoft, l’ID token viene verificato sul nostro server, compresi firma, audience, scadenza e dominio email. Il valore hd di Google viene controllato dal token verificato, non preso per buono dalla richiesta. Per Microsoft sono accettati solo account aziendali e dell’istituto, e l’issuer del token deve corrispondere al suo tenant.

Codici via email

Al posto di Google o Microsoft, un collega può chiedere un codice di 6 cifre al suo indirizzo di lavoro. È così che usano TeamOnly, senza configurare niente, le aziende la cui email non è su Google Workspace o Microsoft 365. Il codice dimostra che controlla una casella di posta su uno dei domini della tua azienda, la stessa cosa che dimostra un accesso con Google o Microsoft. Funziona con qualsiasi provider email. Gli indirizzi personali come Gmail o Outlook.com vengono rifiutati per le app aziendali.

• Un codice scade dopo 10 minuti.
• Dopo cinque tentativi sbagliati il codice smette di funzionare. La persona deve chiederne uno nuovo.
• Un codice funziona solo nel browser che l’ha richiesto. Un codice letto da sopra la spalla di qualcuno, o inoltrato, non serve a niente in un altro browser.
• Le richieste hanno limiti di frequenza per indirizzo email e per indirizzo IP, quindi nessuno può usare il modulo per intasare una casella di posta.
• Il modulo è protetto da Cloudflare Turnstile, che verifica che a chiedere sia una persona e non uno script.
• Il modulo dà la stessa risposta che un indirizzo possa accedere o no, quindi non rivela chi ha accesso.
• I codici partono da signin@teamonly.app, con SPF, DKIM e DMARC configurati, così i provider di posta possono verificare che arrivino davvero da noi.
• I codici vengono salvati solo come hash, e l’accesso viene verificato di nuovo quando il codice viene inserito, nel caso sia cambiato nel frattempo.

Un’identità di cui la tua app può fidarsi

Il Worker di dispatch rimuove qualsiasi header di identità dalla richiesta in arrivo, poi imposta lui stesso email e nome verificati, insieme ai ruoli della persona in quell’app. L’SDK li passa alla tua app come ctx.user.

incoming request to expenses.acme.teamonly.app✖x-teamonly-user: ceo@acme.com    removed, not from us✔x-teamonly-user: dana@acme.com   added from verified sign-in

Database e archiviazione file separati per ogni app

Ogni app riceve un suo database D1, creato alla prima pubblicazione, e un suo prefisso di archiviazione R2 per i file. Sono gli unici binding di dati collegati all’app. Le app girano come script separati in un dispatch namespace di Workers for Platforms e non possono raggiungere i binding delle altre.

Lo testiamo di proposito: un’app che prova a leggere dati, cookie o segreti di un’altra app. Questi test sono stati eseguiti sulla piattaforma in produzione, e li ripetiamo ogni volta che cambiano le parti che tengono separate le app.

Segreti salvati fuori dal codice

I segreti si impostano con npx teamonly secrets set e vengono salvati come Worker secret cifrati, collegati solo a quell’app. Non sono nel tuo repository, non sono nel bundle e non sono visibili alle altre app. Il file della skill dice alla tua AI di non mettere mai chiavi nel codice.

Cookie limitati all’indirizzo di una sola app

I cookie di sessione sono impostati per l’hostname esatto dell’app, come expenses.acme.teamonly.app, con Secure, HttpOnly e SameSite. Non vengono mai impostati su teamonly.app né sul sottodominio dell’organizzazione, quindi un’app non può leggere la sessione di un’altra.

Oggi teamonly.app non è nella Public Suffix List, quindi i browser considerano ogni indirizzo di app come parte di un unico sito quando decidono cosa è same-site. Per questo ogni cookie di sessione è legato all’indirizzo esatto della sua app. Se cambia, lo scriveremo in questa pagina.

Il codice dei clienti è considerato non attendibile

Partiamo dal presupposto che qualsiasi app possa contenere errori o codice ostile, perché in parte l’ha scritta un’AI e chiunque può sbagliare. Per questo l’autenticazione sta fuori dall’app, ogni app riceve solo le sue risorse, e niente di ciò che un’app invia può cambiare chi ha fatto l’accesso. Per lo stesso motivo un’app può inviare email solo alle persone della tua azienda, fino a 100 destinatari all’ora e 500 al giorno.

Dove gira

Tutto gira su Cloudflare: Workers e Workers for Platforms per il codice, D1 per i database, R2 per i file e KV per le sessioni. Non gestiamo server nostri. La scelta della regione dei dati è inclusa nel piano Business, e la configuriamo insieme a te quando ti abboni.

Cosa configuriamo con te, e cosa non facciamo mai

Nel piano Business configuriamo Okta o un altro provider SSO insieme al tuo team IT. Log di audit e regione dei dati vengono configurati con te allo stesso modo. Sono inclusi nel piano, non sono interruttori che attivi da solo.

• Configurato con te
  Okta, OneLogin e altri SSO (piano Business)
• Configurato con te
  Log di audit (piano Business)
• Configurato con te
  Scelta della regione dei dati (piano Business)
• Mai
  App pubbliche, senza autenticazione

Oggi non abbiamo certificazioni SOC 2 o ISO.

Segnalare un problema di sicurezza

Scrivi a hello@teamonly.dev con “Security” nell’oggetto. Una persona legge ogni messaggio, e ti risponderemo per confermare che l’abbiamo ricevuto. Dacci un tempo ragionevole per risolvere il problema prima di renderlo pubblico.