So bleiben Ihre Apps privat und getrennt

Jede Anfrage ist zuerst angemeldet

Der gesamte App-Traffic auf *.teamonly.app geht zuerst an einen einzigen Dispatch-Worker. Er ermittelt Organisation und App aus dem Hostnamen, prüft auf eine gültige Session und leitet die Anfrage erst dann an die App weiter. Ohne Session sieht der Besucher die Anmeldeseite. Kundencode läuft für ihn nie.

Es gibt drei Wege zur Anmeldung: Google OpenID Connect, Microsoft (Entra ID) OpenID Connect oder ein Einmalcode an eine Firmen-E-Mail-Adresse. Bei Google und Microsoft wird das ID-Token auf unserem Server verifiziert, einschließlich Signatur, Audience, Ablauf und E-Mail-Domain. Der hd-Wert von Google wird aus dem verifizierten Token geprüft und nicht aus der Anfrage übernommen. Bei Microsoft werden nur Geschäfts- und Schulkonten akzeptiert, und der Issuer des Tokens muss zum eigenen Tenant passen.

E-Mail-Codes

Statt über Google oder Microsoft kann sich eine Kollegin oder ein Kollege einen 6-stelligen Code an die geschäftliche Adresse schicken lassen. So nutzen Firmen, deren E-Mail nicht über Google Workspace oder Microsoft 365 läuft, TeamOnly ohne Einrichtung. Der Code beweist, dass die Person ein Postfach in einer Ihrer Firmendomains kontrolliert, also dasselbe, was eine Anmeldung über Google oder Microsoft beweist. Er funktioniert mit jedem E-Mail-Anbieter. Private Adressen wie Gmail oder Outlook.com werden für Firmen-Apps abgelehnt.

• Ein Code läuft nach 10 Minuten ab.
• Nach fünf falschen Versuchen funktioniert der Code nicht mehr. Die Person muss einen neuen anfordern.
• Ein Code funktioniert nur in dem Browser, der ihn angefordert hat. Ein Code, den jemand über die Schulter mitgelesen oder weitergeleitet bekommen hat, nützt in einem anderen Browser nichts.
• Anfragen sind pro E-Mail-Adresse und pro IP-Adresse begrenzt, damit niemand mit dem Formular ein Postfach fluten kann.
• Das Formular ist durch Cloudflare Turnstile geschützt, das prüft, ob ein Mensch fragt und kein Skript.
• Das Formular antwortet gleich, egal ob sich eine Adresse anmelden kann oder nicht. So verrät es nicht, wer Zugang hat.
• Codes werden von signin@teamonly.app verschickt, mit eingerichtetem SPF, DKIM und DMARC, damit Mailanbieter prüfen können, dass sie wirklich von uns kommen.
• Codes werden nur als Hash gespeichert, und der Zugang wird bei der Eingabe des Codes erneut geprüft, falls er sich inzwischen geändert hat.

Eine Identität, der Ihre App vertrauen kann

Der Dispatch-Worker entfernt alle Identitäts-Header der eingehenden Anfrage und setzt dann selbst die verifizierte E-Mail und den Namen, zusammen mit den Rollen der Person in dieser App. Das SDK stellt sie Ihrer App als ctx.user bereit.

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

Eigene Datenbank und eigener Dateispeicher pro App

Jede App bekommt ihre eigene D1-Datenbank, angelegt bei der ersten Veröffentlichung, und ihr eigenes R2-Speicherpräfix für Dateien. Das sind die einzigen Daten-Bindings, die an die App angehängt sind. Apps laufen als getrennte Skripte in einem Dispatch-Namespace von Workers for Platforms und können die Bindings der anderen nicht erreichen.

Das testen wir gezielt: eine App, die versucht, Daten, Cookies oder Secrets einer anderen App zu lesen. Diese Tests liefen gegen die Live-Plattform, und wir wiederholen sie, sobald sich die Teile ändern, die Apps voneinander trennen.

Secrets außerhalb Ihres Codes gespeichert

Secrets werden mit npx teamonly secrets set gesetzt und als verschlüsselte Worker-Secrets gespeichert, die an genau diese eine App gebunden sind. Sie liegen nicht in Ihrem Repository, nicht im Bundle und sind für andere Apps nicht sichtbar. Die Skill-Datei weist Ihre KI an, Schlüssel nie in den Code zu schreiben.

Cookies gelten nur für die Adresse einer App

Session-Cookies werden für den exakten Hostnamen der App gesetzt, etwa expenses.acme.teamonly.app, mit Secure, HttpOnly und SameSite. Sie werden nie auf teamonly.app oder die Subdomain der Organisation gesetzt, also kann eine App die Session einer anderen nicht lesen.

teamonly.app steht heute nicht auf der Public Suffix List. Browser zählen deshalb jede App-Adresse zur selben Site, wenn sie entscheiden, was same-site ist. Darum ist jedes Session-Cookie an die exakte Adresse seiner App gebunden. Ändert sich das, steht es auf dieser Seite.

Kundencode gilt als nicht vertrauenswürdig

Wir gehen davon aus, dass jede App Fehler oder schädlichen Code enthalten kann, weil eine KI einen Teil davon geschrieben hat und jedem ein Fehler passieren kann. Deshalb liegt die Authentifizierung außerhalb der App, deshalb bekommt jede App nur ihre eigenen Ressourcen, und deshalb kann nichts, was eine App sendet, ändern, wer angemeldet ist. Deshalb kann eine App auch nur Personen in Ihrer Firma E-Mails schicken, mit bis zu 100 Empfängern pro Stunde und 500 pro Tag.

Wo es läuft

Alles läuft auf Cloudflare: Workers und Workers for Platforms für den Code, D1 für Datenbanken, R2 für Dateien und KV für Sessions. Eigene Server betreiben wir nicht. Die Wahl der Datenregion ist im Business-Tarif enthalten, und wir richten sie beim Start mit Ihnen ein.

Gemeinsam mit Ihnen eingerichtet, und was wir nie tun

Im Business-Tarif richten wir Okta oder einen anderen SSO-Anbieter mit Ihrer IT ein. Audit-Logs und Ihre Datenregion werden auf die gleiche Weise mit Ihnen konfiguriert. Sie sind im Tarif enthalten, aber keine Schalter, die Sie selbst umlegen.

• Gemeinsam mit Ihnen eingerichtet
  Okta, OneLogin und anderes SSO (Business-Tarif)
• Gemeinsam mit Ihnen eingerichtet
  Audit-Logs (Business-Tarif)
• Gemeinsam mit Ihnen eingerichtet
  Wahl der Datenregion (Business-Tarif)
• Nie
  Öffentliche Apps ohne Anmeldung

Eine SOC-2- oder ISO-Zertifizierung haben wir derzeit nicht.

Ein Sicherheitsproblem melden

Schreiben Sie an hello@teamonly.dev mit „Security“ im Betreff. Ein Mensch liest jede Nachricht, und wir bestätigen Ihnen den Eingang. Bitte geben Sie uns eine angemessene Chance, ein Problem zu beheben, bevor Sie es veröffentlichen.