Login Options

[nicholaswilde]

I don't know what your roadmap for this project looks like, but I thought I'd share my feedback on login methods.

Here's a few options that would be nice to have:

1. LDAP or OpenID Connect to use with login services, such as Authentik.
2. Initial account creation using environmental variables so that the admin doesn't need to create an initial user on initial deployment.
3. Disable sign-ups, similar to Mealie.
4. Completely disable logins and just have the initial user logged in at all times. This is great for home labs where a single user is using LW on a private network.

[Polliog]

Thanks for the detailed feedback! Authentication flexibility is definitely something we're thinking about, especially for self-hosted deployments where needs vary widely.

Let me address each of your suggestions:

1. LDAP / OpenID Connect (OIDC)

This is on the roadmap, OIDC integration would cover most SSO scenarios including Authentik, Keycloak, and other identity providers. This would likely come before native LDAP since OIDC is more widely adopted and covers more use cases.

2. Initial Admin via Environment Variables

Great suggestion and actually quite straightforward to implement. Something like:

LOGWARD_ADMIN_EMAIL=admin@example.com
LOGWARD_ADMIN_PASSWORD=secure_password_here
LOGWARD_ADMIN_ORG=Default

This would create the initial user on first boot if no users exist. I'll actually prioritize this

3. Disable Sign-ups

Absolutely makes sense, especially for private deployments. An environment variable like:

LOGWARD_DISABLE_SIGNUPS=true

4. Auth-free Mode for Home Labs

Interesting idea! While I understand the convenience for single-user home labs, I'm a bit hesitant about this one for a few reasons:

• Security best practice: Even in home labs, having some authentication is generally advisable
• Accidental exposure: If the deployment accidentally becomes internet-facing, you're immediately vulnerable
• Feature complexity: Some features (API keys, multi-org, audit logs) assume an authenticated user context

Alternative approach:
What if instead we had a "single-user mode" with a simple PIN or token-based auth that persists in local storage? It would be minimal friction but still provide a basic security boundary.

Or, if you're on a completely isolated network, you could potentially run LogWard behind a reverse proxy (Traefik, Nginx) with basic auth at the proxy level and keep LogWard auth disabled via feature flag.

Would either of those approaches work for your use case?

---

Thanks again for the thoughtful suggestions , this kind of feedback is incredibly valuable!

[nicholaswilde]

Appreciate the response to the feedback.

4. Auth-free Mode for Home Labs
   Security best practice: Even in home labs, having some authentication is generally advisable.

Yeah, that's what I figured. It was worth putting it out there.

What if instead we had a "single-user mode" with a simple PIN or token-based auth that persists in local storage? It would be minimal friction but still provide a basic security boundary.

I think my preference would be the "single-user mode" out of the two, but even the current method is okay.

[Polliog]

Okok i will add it to the roadmap