> ## Documentation Index
> Fetch the complete documentation index at: https://supastack.dev/llms.txt
> Use this file to discover all available pages before exploring further.
> For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt

# SaaS mit Chrome-Extension (MV3) bauen: Web-Auth & API teilen

Die meisten Teams bauen ein zweites Backend für ihre Browser-Extension. So verdrahten Sie einen Manifest-V3-Companion stattdessen über Workspace-API-Keys mit Ihrem bestehenden SaaS – ohne doppelte Auth, ohne zweite Datenbank.

_Veröffentlicht 2026-11-07._
_Aktualisiert am 2026-11-07._

> **Wie baut man eine Chrome-Extension, die das Backend des eigenen SaaS teilt?**
> Indem man kein zweites Backend baut. MV3-Extensions können sich nicht auf HttpOnly-Cookies verlassen, daher authentifiziert man mit Workspace-API-Keys: Die Extension ruft die versionierte REST-API (/api/v1) der App mit einem Scoped Key auf, der an genau einen Workspace gebunden ist – und nutzt damit dasselbe Auth-Modell, dasselbe Tenant-Scoping und dieselbe Postgres-Datenbank wie die Web-App. Genau so ist supastacks MV3-Scaffold verdrahtet – Popup, Options-Seite, Background-Worker, Least-Privilege-Manifest.

## Die Falle: ein zweites Backend, ohne es zu merken

Die übliche Geschichte: Ihr SaaS braucht eine Companion-Extension – um Seiten zu erfassen, Content zu clippen oder das Web zu annotieren. Sechs Monate später pflegen Sie zwei Auth-Systeme (Cookies fürs Web, irgendein handgebautes Konstrukt für die Extension), eine Parallel-API, die die Extension wirklich aufrufen kann, und eine Sync-Schicht, die zwei Datenbestände zusammenhält, die eigentlich einer sein sollten.

Nichts davon ist nötig. Die Extension ist nur ein weiterer Client Ihres bestehenden Produkts – sie braucht eine Credential, die sie halten kann, und eine API, die für programmatischen Zugriff gebaut ist. Der Fehler ist, nach einem neuen Backend zu greifen, statt die Workspace-API-Keys und die versionierte REST-Oberfläche zu nutzen, die ein ernstes SaaS längst hat.


## Was Manifest V3 tatsächlich erlaubt

MV3 hat Background-Pages durch kurzlebige Service Worker ersetzt und Extensions auf Least Privilege gedrängt. Praktisch heißt das: kein persistenter In-Memory-State, kein Cookie-Kratzen für Session-Reuse (HttpOnly-Cookies sind ohnehin unerreichbar) und jede Host-Permission ist eine Frage im Web-Store-Review.

Die saubere Antwort ist das, was die Plattform längst bietet: eine Scoped Credential in `chrome.storage.local` und HTTPS-Calls an den Origin Ihrer App – angefragt als optionale Host-Permissions zur Setup-Zeit, nicht zur Installationszeit.


## supastacks MV3-Scaffold: was bereits verdrahtet ist

supastacks `apps/extension` ist ein bewusst kleines, frameworkloses Manifest-V3-Companion – »Seite im Workspace speichern« – das das gesamte Muster Ende zu Ende zeigt. Es speichert Titel, URL und selektierten Text des aktiven Tabs als Workspace-Content-Entry über die versionierte REST-API `POST /api/v1/content-entries`.

Auth läuft über einen Workspace-API-Key (`sk_…`), der unter Settings → Developers erstellt wird: Der Key ist an genau einen Workspace gebunden, also ist die Bindung selbst die Workspace-Auswahl – der Key kann nirgendwo anders hinschreiben. Die Options-Seite persistiert App-URL und Key in `chrome.storage.local`, fordert Zugriff nur für diesen Origin an und verifiziert die Verbindung über `GET /api/v1/workspaces/current`.

```
apps/extension/
  manifest.json        MV3: service worker, least-privilege permissions
  src/
    background.js      context-menu save + badge feedback
    popup.html/.js     capture UI — title, URL, selection, note
    options.html/.js   app URL + workspace API key setup
    lib/
      api.mjs          versioned /api/v1 client (key auth)
      capture.mjs      active-tab + selection capture
      config.mjs       chrome.storage.local persistence
```


## Least Privilege per Default

Der Scaffold enthält nur die minimale Permission-Menge, die die Aufgabe braucht – wichtig für Web-Store-Review und Nutzervertrauen:

- Kein `tabs`, kein `<all_urls>`, kein cookies/webRequest/declarativeNetRequest – ein Scaffold, der ehrlich deklariert, was er nicht braucht.

| Berechtigung | Wofür |
|---|---|
| activeTab | Titel/URL der aktuellen Seite nur bei Aufruf lesen |
| scripting | Selektierten Text im aufgerufenen Tab lesen |
| contextMenus | Rechtsklick-Speichern-Eintrag registrieren |
| storage | App-URL, API-Key und Workspace-Cache persistieren |
| optional_host_permissions | App-Origin wird zur Setup-Zeit angefragt – null Site-Zugriff bei Installation |


## Vom Scaffold zum Companion Ihres Produkts

Rebranding ist eine Namensänderung im `manifest.json`; die Erweiterung ist der spannende Teil – und bleibt im selben Muster: Neue Capture-Typen rufen neue `/api/v1`-Endpoints mit demselben Key auf, und das aus der OpenAPI-Doku der App generierte typisierte `@supastack/api-sdk` hält Request-Shapes ehrlich.

Weil die Extension über dieselbe tenant-gescopte API liest und schreibt wie jeder andere Client, landen gespeicherte Seiten in denselben Postgres-Zeilen, die das Web-Dashboard auflistet – eine Datenbank, ein Auth-Modell, `workspaceId`-Scoping an genau einer Stelle erzwungen. Kein zweites Backend, kein Sync, kein Drift. Stufen auf der [Pricing-Seite](https://supastack.dev/#pricing) vergleichen.

|  | DIY-Zweit-Backend | supastack MV3-Scaffold |
|---|---|---|
| Auth | Handgebautes Token-System neben Cookies | Workspace-API-Keys – dasselbe Auth-Modell wie Web |
| API | Neue Endpoints nur für die Extension | Versionierte /api/v1 + OpenAPI-typisiertes SDK |
| Daten | Zweiter Store + Sync-Logik | Dieselben Postgres-Zeilen, workspace-gescoped |
| Berechtigungen | Breiter Zugriff aus Bequemlichkeit | Least-Privilege-Manifest, review-freundlich |


## FAQ: SaaS + Chrome-Extension auf einem Backend

Fragen, die Entwickler vor dem Launch eines Extension-Companions stellen:

- Warum ein API-Key statt des Session-Cookies des Nutzers?, HttpOnly-Cookies sind für Extension-JS per Design unsichtbar und MV3-Service-Worker sind kurzlebig – ein Scoped `sk_…`-Key in `chrome.storage.local` ist persistent, widerrufbar und an einen Workspace gebunden, sodass er nie tenant-übergreifend schreiben kann.
- Funktioniert die Extension unter Firefox?, MV3 unterstützt dieselbe Oberfläche; der Code nutzt einen `browser ?? chrome`-Namespace-Shim und wird Chromium-first entwickelt – Firefox ist also ein Port, kein Rewrite.
- Ist sie direkt store-ready?, Es ist ein Produktionsmuster-Scaffold, kein Store-Submission – Sie benennen das Manifest um, fügen eigene Capture-Logik hinzu und schreiben den Listing-Text. Der schwere Teil (Auth, API, Tenant-Scoping) ist fertig.
- Welche Stufe enthält die Extension?, Das $299 Full Bundle liefert alle fünf Oberflächen – zwei Web-Engines, Expo, Tauri und den Extension-Scaffold – in einem Repo.