osFoundry / Platform
Besucher-Authentifizierung
Anonym, Magic-Link, OAuth oder Workspace-SSO für öffentliche Apps. Pro Route mischen und kombinieren.
Was es ist
Die Besucher-Authentifizierung entscheidet in osFoundry, wer jede Route einer App erreicht, die du veröffentlichst. Wenn du eine App aus deinem Workspace ausspielst, geht sie unter einer öffentlichen URL online, und jede Route kann ihre eigene Eingangstür tragen: Lass eine Seite für anonyme Besucher vollständig offen, sichere eine andere hinter einem Magic Link an eine E-Mail-Adresse, verlange die Anmeldung über einen OAuth-Anbieter oder beschränke eine Route per SSO auf Mitglieder deines osFoundry-Workspace. Du entscheidest pro Route statt für die ganze App, sodass eine Marketing-Landingpage, ein geschütztes Tool und eine interne Admin-Ansicht im selben Deployment unter unterschiedlichen Regeln nebeneinander bestehen können.
In osFoundry liegen die App und ihre Authentifizierung im selben Workspace wie dein Chat, deine Agenten, dein Code und deine Daten. Du musst keinen separaten Identitätsdienst aufsetzen und keine Session-Verwaltung von Hand schreiben: Du hängst einer Route eine Methode an, und die Plattform setzt sie bei jeder Anfrage vor der App durch. Weil osFoundry ein BYOK- und Local-First-Workspace ist, entscheidet die Wahl der Authentifizierung nur darüber, wer deine veröffentlichte App erreicht; sie leitet deinen Modell-Traffic nicht über einen Reseller und legt keine Sitzplatzgebühr für jede angemeldete Person drauf. Anonymer Zugang bleibt wirklich anonym, Magic Links kommen ganz ohne Passwörter aus, OAuth nutzt Konten wieder, die deine Besucher ohnehin haben, und Workspace-SSO hält interne Tools auf dein Team begrenzt.
Worauf es ankommt, ist das Modell „pro Route kombinieren". Eine einzelne öffentliche App will selten ein einheitliches Tor. Die Besucher-Authentifizierung lässt eine öffentliche App eine offene Front zeigen und dahinter die Aktionen schützen, und lässt eine interne App reine SSO bleiben, ohne die App in getrennte Deployments zu zerlegen oder für jede Seite eigene Middleware zu schreiben.
Wichtige Funktionen
- Anonymer Zugang: Öffentliche Routen ganz ohne Anmeldung offen lassen, für Landingpages und Nur-Lese-Ansichten
- Magic-Link-Anmeldung: Besucher per Einmal-Link in einer E-Mail authentifizieren, keine Passwörter zu speichern oder zurückzusetzen
- OAuth: Besucher mit Konten anmelden lassen, die sie bereits bei einem OAuth-Anbieter haben
- Workspace-SSO: Routen für interne Tools auf Mitglieder deines osFoundry-Workspace beschränken
- Konfiguration pro Route: Unterschiedliche Authentifizierungsmethoden auf unterschiedliche Routen derselben veröffentlichten App anwenden
Anwendungsfälle
- Indie-Entwickler: veröffentlicht ein Tool mit offener anonymer Landingpage und legt den eigentlichen Generator hinter einen Magic Link, damit die Nutzung an eine E-Mail gebunden ist
- Teamleitung: spielt ein internes Dashboard aus dem Workspace aus und sperrt jede Route per Workspace-SSO, damit nur Teammitglieder es öffnen
- Produktteam: betreibt eine öffentliche App, in der die Doku anonym ist, das kostenlose Tool OAuth-Anmeldung nutzt und das Admin-Panel nur für den Workspace zugänglich ist
Häufig gestellte Fragen
Können verschiedene Seiten derselben App verschiedene Anmeldemethoden nutzen?
Ja. Die Besucher-Authentifizierung wird pro Route konfiguriert, sodass eine veröffentlichte App einige Routen anonym lassen, andere hinter einem Magic Link oder OAuth sichern und wieder andere auf Workspace-SSO beschränken kann, ohne sie in getrennte Deployments aufzuteilen.
Was ist hier der Unterschied zwischen OAuth und Workspace-SSO?
OAuth lässt externe Besucher mit Konten anmelden, die sie bereits bei einem OAuth-Anbieter haben, was zu öffentlichen Apps passt. Workspace-SSO beschränkt eine Route auf Mitglieder deines osFoundry-Workspace, was zu internen Tools passt, die die Öffentlichkeit nicht erreichen soll.
Bedeuten authentifizierte Besucher, dass man pro Sitzplatz zahlt?
Nein. osFoundry hat keine Sitzplatzgebühren, und die Besucher-Authentifizierung steuert, wer deine veröffentlichte App erreicht, statt für jede angemeldete Person eine Gebühr zu erheben. Sie ist Teil der Apps-&-Backend-Schicht des Workspace, kein separates Identitäts-Abo.