Skip to content

[Feature Request] - Add Native Password / Token Authentication (Required for Secure Public Self-Hosting) #81

@hellotimking

Description

@hellotimking

KOInsight currently ships with no built-in authentication on the web UI.
When self-hosted on a public VPS, this makes the app effectively unusable unless it’s hidden behind network-level controls.

Adding HTTP Basic Auth at the reverse proxy level (Caddy / Nginx) does secure the UI — but it breaks the KOReader plugin, which cannot authenticate against Basic Auth–protected endpoints.

This creates an all-or-nothing situation:

  • Public VPS → insecure
  • Reverse-proxy auth → plugin stops working

KOInsight is excellent, but without built-in authentication it cannot be safely self-hosted on a public server. Reverse-proxy auth breaks the plugin, leaving no viable secure deployment path.

Adding native auth would immediately unlock real-world VPS deployments and make KOInsight production-ready.

Happy to test or help validate any auth approach (password, token, header-based) if this moves forward.


Requested Feature

Add native application-level authentication to KOInsight, for example:

  • Username/password login for the web UI
  • Token-based auth or API key support for the KOReader plugin
  • Optional ability to disable auth for local-only deployments

The key requirement is auth handled inside the app, not delegated to the reverse proxy.


Why This Matters

Self-hosting on a public VPS is a completely normal deployment model, but exposing reading history, highlights, and metadata without auth is a non-starter. This blocks adoption for anyone who isn’t running KOInsight on a private LAN

Right now, KOInsight is functionally insecure by default when deployed publicly.


Suggested Implementation (Non-Prescriptive)

Any of the following would solve the problem:

  • Simple username/password auth stored locally
  • API tokens scoped for plugin access
  • Header-based auth support (e.g. Authorisation: Bearer)
  • Env-based credentials for containerised deployments

The exact approach is up to you — but some form of first-class auth is essential.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions