Headless Auth Server Mode: Keep OAuth, Own the UI
Hosted login is the fast default. When you need your own authorize UI, SqlOS headless keeps OAuth in SqlOS and the pixels in your app.
By SqlOS Team
Hosted login ships fast. One place for the browser flow.
Later, teams often want:
- A popup that matches the product
- Signup tests without fighting the hosted page
- Extra fields and tuning
- “Our UI” without rewriting OAuth
That is headless in SqlOS.
The problem with most auth products
Pick one:
- Use their hosted page.
- Rebuild everything.
(1) is safe for protocol. (2) drags you into redoing:
- Auth requests
- Redirect checks
- PKCE
- Callbacks
- Codes
Pretty UI. Sketchy plumbing.
What we wanted instead
Split the work:
- SqlOS:
/sqlos/auth/authorize,/sqlos/auth/token, PKCE, redirects, OIDC/SAML callbacks, codes, tokens - Your app: the screens
Headless is not “throw away SqlOS auth.”
It is: SqlOS = protocol. You = pixels.
Why this matters for OAuth-powered MCP
MCP and similar clients use an authorize popup. That popup is your product surface.
Generic hosted chrome feels bolted on.
Headless keeps:
- The same SqlOS OAuth server
- The same metadata and token flow
- A popup that looks like your app
The example we wanted to prove
The SqlOS example app shows:
- Hosted vs headless side by side
- Custom shell at
/auth/authorize - Extra signup field
referralSource - Saved in
OnHeadlessSignupAsync - Read back through a normal API
Not just prettier HTML. Your data and UX. SqlOS still owns the server.
Our view
Default stays hosted. Good for many teams.
The real fork is not “hosted vs build your own auth server.”
It is hosted vs headless SqlOS.
Guides: