Skip to content

[Feature]: Optional multi-user authentication and per-user isolation #181

Description

@CNXWZY

Problem

Neo Chat is very suitable for self-hosting, especially with its Cloudflare Workers deployment support and configurable model providers.

However, the current ACCESS_PASSWORD appears to be a deployment-wide access gate rather than a real user account system. This works well for personal use, but makes it difficult to safely deploy one Neo Chat instance for a small team, family, or private community.

My intended use case is:

  • Deploy a single Neo Chat instance on Cloudflare Workers.
  • Allow multiple users to sign in with separate accounts.
  • Allow the administrator to enable or disable individual users.
  • Keep each user's settings, provider credentials, and conversations isolated.
  • Optionally allow all users to access a deployment-level provider configured by the administrator.

Browser-local storage provides some separation between devices, but without user identities there is no way to revoke access for one person, distinguish users, or safely manage a shared deployment.

Is optional multi-user authentication currently planned for Neo Chat?

Proposal

A minimal useful version could remain optional and preserve the current local-first, single-user behavior by default.

Possible MVP:

  1. Add an optional authentication mode that can be enabled through environment variables.
  2. Support either:
    • administrator-created username/password accounts;
    • OIDC/OAuth authentication; or
    • trusted identity headers from Cloudflare Access or another reverse proxy.
  3. Assign every authenticated user a stable user ID.
  4. Namespace any shared server-side data and temporary state by user ID.
  5. Ensure that user-provided provider keys and settings cannot be accessed by other users.
  6. Add basic session management and logout.
  7. Allow an administrator to enable, disable, or remove users.

More advanced features such as registration, usage quotas, billing, invitation emails, synchronized chat history, and organization roles could be added later and would not need to be part of the initial implementation.

I am mainly interested in a lightweight multi-user mode for private self-hosted deployments, rather than a complete public SaaS platform.

If this is not currently on the roadmap, would the maintainers be open to a community contribution? If so, is there a preferred authentication approach or architecture that a pull request should follow?

Area

Chat

Alternatives considered

No response

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions