[Feature Request] Configurable authentication session lifetime

[Metus88]

Homepage 2.0 introduced native authentication, which is a very useful addition.

It would be useful to also make the authentication session lifetime configurable, so users can choose how long a successful login remains valid before authentication is required again.

Currently, the authentication settings expose options for enabling authentication, the authentication secret, password/OIDC configuration, and the external URL, but there does not appear to be a configuration option for the session lifetime.

Proposed behavior

An optional environment variable could be added, for example:

HOMEPAGE_AUTH_SESSION_MAX_AGE=604800

where the value is expressed in seconds (604800 = 7 days).

The exact variable name and format are of course just a suggestion; a duration expressed in days or another format would work as well.

If the variable is not set, Homepage could simply retain its current default session lifetime, keeping the change fully backward-compatible.

Use case

Different installations may have different security and convenience requirements.

For example:

a trusted LAN-only installation may prefer a relatively long-lived session;
an Internet-accessible installation may prefer authentication to expire sooner;
users may want to require authentication again after 1, 7, 14, or 30 days.

Making the session lifetime configurable would allow users to choose the appropriate balance between convenience and security without modifying the Homepage source code.

This would be a useful complement to the native authentication functionality introduced in Homepage 2.0.

UPDATE:

I also checked the current dev branch and, at the moment, the authentication configuration still appears to use the default JWT session settings without exposing a configurable maxAge.

Since next-auth already supports session.maxAge, this feature may be relatively straightforward to expose through an optional Homepage environment variable, while preserving the current default behavior when the variable is not set.

For example, conceptually:

session: {
  strategy: "jwt",
  maxAge: ...
}

This is only meant as additional context for the request; the exact implementation and configuration format would of course be up to the maintainers.