Move authsome to a client server architecture

[manojbajaj95]

Maybe this will help us, server can render a simple ui, handle callbacks, device flow. The cli becomes the client. This can help us simplify the design a lot.

[manojbajaj95]

Brainstorming notes:

The client-server direction looks useful, but I would avoid making it a wholesale move at first. A better framing is: add an optional local auth server/daemon while keeping authsome lightweight and usable as a direct CLI/library by default.

Recommended architecture:

Core library
  Provider registry, vault, profiles, credential records, flow logic.

Optional local server / daemon
  Local API, callback routes, login orchestration, UI surface, diagnostics.

CLI client
  Uses the local server when available or when a flow benefits from it, but can still call core directly for simple non-interactive commands.

Why this helps:

• PKCE callback handling becomes centralized instead of each flow spinning up ad hoc callback handling.
• The UI idea from A UI to see configured agents, available profiles and connections #96 fits naturally: the server can render a simple local operator console.
• Device code and API key bridge flows can share the same local interaction surface.
• The CLI can become thinner over time without forcing every command to require a daemon.
• A server abstraction gives us a future path toward richer orchestration without changing the core storage model.

Important constraint:

Authsome should remain lite by default. Server/UI dependencies should not be required for the base CLI/library install. Prefer optional extras or extension packaging:

authsome              # lightweight CLI/library
authsome[server]      # local server / daemon
authsome[ui]          # local management UI
authsome[all]         # everything

Or potentially separate packages later (authsome-server, authsome-ui) if extras become too coupled.

Suggested responsibilities for the local server:

• Local callback listener for OAuth flows.
• Flow/session orchestration for login.
• Device code progress/status page.
• API key/browser bridge input surface.
• Local UI for profiles, providers, connections, diagnostics.
• Refresh coordination and health checks.

Responsibilities to avoid in the first version:

• Hosted/cloud dashboard behavior.
• Team credential sharing.
• Multi-user remote server semantics.
• Binding to public interfaces by default.
• Replacing the core library as the only way to read credentials.

Security baseline:

• Bind to 127.0.0.1 by default.
• Require explicit opt-in for any non-local bind address.
• Use a local session/bearer token for API access.
• Use CSRF protection for UI forms.
• Never render secrets by default.
• Do not log tokens, API keys, client secrets, auth codes, or refresh tokens.
• Keep auth flow IDs short-lived and validate OAuth state strictly.

Possible local API shape:

GET  /health
GET  /profiles
POST /profiles
GET  /providers
GET  /providers/{name}
GET  /profiles/{profile}/connections
POST /auth-flows
GET  /auth-flows/{id}
POST /profiles/{profile}/logout/{provider}/{connection}
POST /profiles/{profile}/revoke/{provider}
GET  /oauth/callback/{flow_id}
GET  /ui

Implementation path:

1. Extract callback handling behind an interface so PKCE is no longer tied to one hardcoded ad hoc server shape.
2. Add an optional authsome server start/status/stop surface with a minimal /health endpoint and callback route.
3. Move PKCE login orchestration to server-backed mode while preserving the current direct CLI path.
4. Add the local UI from A UI to see configured agents, available profiles and connections #96 as an optional dependency/extension, initially read-mostly.
5. Move API key bridge, device code progress, and DCR+PKCE into the same flow/session model.
6. Only after this is stable, decide whether the CLI should auto-start/use the server by default for interactive commands.

Preferred decision for now:

Do not force a full move to client-server yet. Keep authsome CLI/library-first and lightweight, then add an optional local server as the shared home for callbacks, UI, and interactive flow orchestration.