osFoundry / Platform
Visitor authentication
Anonymous, magic-link, OAuth or workspace SSO for public apps. Mix and match per route.
What it is
Visitor authentication is how osFoundry decides who reaches each route of an app you publish. When you ship an app from your workspace, it goes out at a public URL, and every route can carry its own front door: leave a page fully open for anonymous visitors, gate another behind a magic link sent to an email address, require sign-in with an OAuth provider, or restrict a route to members of your osFoundry workspace over SSO. You choose per route rather than for the whole app, so a marketing landing page, a gated tool, and an internal admin view can live in the same deployment under different rules.
Inside osFoundry the app and its auth live in the same workspace as your chat, agents, code, and data. You don't stand up a separate identity service or hand-write session handling: you attach a method to a route, and the platform enforces it in front of the app on every request. Because osFoundry is a bring-your-own-key, local-first workspace, the auth choice is about who reaches your published app — it doesn't route your model traffic through a reseller or add a per-seat charge for the people who sign in. Anonymous access stays truly anonymous, magic links avoid passwords entirely, OAuth reuses accounts your visitors already have, and workspace SSO keeps internal tools scoped to your team.
The "mix and match per route" model is the point worth understanding. A single public app rarely wants one uniform gate. Visitor authentication lets a public app expose an open front while protecting the actions behind it, and lets an internal app stay SSO-only, all without splitting the app into separate deployments or writing bespoke middleware for each page.
Key capabilities
- Anonymous access: leave public routes fully open with no sign-in, for landing pages and read-only views
- Magic-link sign-in: authenticate visitors by emailing a one-time link, no passwords to store or reset
- OAuth: let visitors sign in with accounts they already have from an OAuth provider
- Workspace SSO: restrict routes to members of your osFoundry workspace for internal tools
- Per-route configuration: apply different auth methods to different routes in the same published app
Use cases
- Indie builder: publishes a tool with an open anonymous landing page and puts the actual generator behind a magic link so usage is tied to an email
- Team lead: ships an internal dashboard from the workspace and locks every route to workspace SSO so only teammates can open it
- Product team: runs one public app where the docs are anonymous, the free tool uses OAuth sign-in, and the admin panel is workspace-only
Frequently asked questions
Can different pages of the same app use different sign-in methods?
Yes. Visitor authentication is configured per route, so one published app can leave some routes anonymous, gate others behind a magic link or OAuth, and restrict others to workspace SSO, without splitting it into separate deployments.
What's the difference between OAuth and workspace SSO here?
OAuth lets outside visitors sign in with accounts they already have from an OAuth provider, which suits public apps. Workspace SSO restricts a route to members of your osFoundry workspace, which suits internal tools you don't want the public to reach.
Does adding authenticated visitors mean paying per seat?
No. osFoundry has no per-seat fees, and visitor authentication controls who reaches your published app rather than adding a charge for each person who signs in. It's part of the Apps & Backend layer of the workspace, not a separate identity subscription.