How Does Immich Handle Authentication Across Local and Remote Sessions?
Immich keeps account identity server-side while local and remote clients present session credentials through paths that can differ in origin, proxy, and redirects.
The user may be identical on LAN and away from home, yet the browser, mobile app, reverse proxy, and identity provider do not handle every transition alike. Authentication failures should therefore be traced from credential issuance through transport to server validation.
Identity and Session Credentials Are Different Layers
Authentication first proves an identity, then subsequent requests present session material that the server validates. A correct password or identity-provider result can coexist with later session failure if a token is missing, expired, stored under another origin, or sent through a path the server interprets differently.
An independent guide to configuring Authelia OIDC for Immich shows an external identity provider participating in sign-on while Immich remains the destination application. This clarifies the boundary: the provider establishes identity through redirects, but Immich still maps the result to its own user and session behavior.
When debugging, record whether failure occurs before credentials are accepted, during the redirect callback, or on a later API request. Those points implicate different components. Repeatedly resetting passwords cannot fix a callback URL mismatch, and proxy edits cannot repair a disabled Immich account.
Local and Remote URLs Create Different Client Contexts
A local address and a public hostname may reach the same Immich container, but clients see different schemes, hosts, certificates, DNS answers, and proxy hops. Browsers partition storage by origin, while native clients can apply their own redirect and certificate rules. Session continuity does not automatically cross those boundaries.
A Caddy community case reports Authelia working for Immich in a web browser while the mobile app produces errors. That is one proxy design, but it demonstrates the broader point that successful browser authentication does not validate a native clientโs redirect and API flow.
Test each supported combination explicitly: LAN browser, remote browser, LAN mobile, and remote mobile. Record the exact URL and failure step. If only one context fails, compare its certificate chain, redirect URI, cookie or token handling, and DNS route before changing shared user permissions.
The Proxy Must Preserve the Request Context
A reverse proxy terminates or forwards transport before requests reach Immich. The application may rely on forwarded scheme, host, and client information to generate links or assess request context. Incorrect translation can make callbacks point to the wrong origin or make an otherwise valid session appear inconsistent.
The ZimaSpace Immich data-path article emphasizes that visible application behavior crosses several dependencies rather than one container boundary. Authentication follows the same reasoning: DNS, TLS termination, proxy routing, the application, and any identity provider all participate before an authenticated media request succeeds.
Inspect the browser network trace or mobile proxy logs from initial login through one authenticated API request. Confirm the externally visible scheme and host remain consistent at redirects. Then verify the application receives the intended forwarding information. Change one proxy setting at a time and preserve a known working LAN path.
Verify Session Continuity With a Path Matrix
Build rows for browser and mobile, with columns for LAN and remote access. For each cell, test fresh login, page or timeline reload, application restart, token renewal after time passes, logout, and access to an asset owned by another test account. Never use production-only photos for permission testing.
A secure remote-access guide for Immich covers HTTPS tunneling, remote connectivity, monitoring, and troubleshooting. Its architectural value is that remote availability adds an access layer around the application; that layer must be tested without assuming it changes Immichโs underlying user ownership or authorization model.
Classify failures by the first broken step: reachability, TLS, redirect, credential acceptance, session persistence, or asset authorization. The matrix is complete only when both success and intended denial are observed. A session that stays logged in but exposes the wrong userโs assets is not an authentication success.
Recommended products
Tech & AI HUB
More to Read
What Is Immich State, and Which Parts Must Persist?
Immich state includes originals, database relationships, identity, configuration, and derivatives; persist each according to whether it is reconstructable.
What Causes Immich Search or Query Results to Slow as Data Grows?
Immich growth can enlarge indexes, evict hot pages, complicate filters, and delay media delivery; separate these stages before tuning.
Why Does Immich Behave Differently After a Container Restart?
After an Immich restart, transient cache loss is expected; lasting login, database, or media changes point to dependency or persistence faults.
