starred/photoprism

Fork 0

mirror of https://github.com/photoprism/photoprism.git synced 2026-03-02 22:57:18 -05:00

Security: use proxy header for username #2391

New issue

Closed

opened 2026-02-20 01:10:52 -05:00 by deekerman · 4 comments

deekerman commented

2026-02-20 01:10:52 -05:00

Owner

Originally created by @pseudocoder on GitHub (Aug 30, 2025).

Describe what problem this solves and why this would be valuable to many users

A common pattern for proxies is to implement SSO and then pass on the authenticated username in a header (e.g. X-Auth-User), which is a much simpler pattern than some other SSO solutions like OAUTH. It would be great if PhotoPrism could also support this in the new multi-user option, then for me Plus would be worthwhile.

Describe the solution you'd like

Implement authentication via a header from upstream proxy.

The name of the header to check should be configurable, and users should still be created and managed via the admin UI.

Describe alternatives you've considered

If this is already the authentication used for other services (as in my case), implementing an alternative is not suitable.

Additional context

A couple of examples where this is implemented - Grafana, Calibre-Web. There are many more.

Originally created by @pseudocoder on GitHub (Aug 30, 2025). **Describe what problem this solves and why this would be valuable to many users** A common pattern for proxies is to implement SSO and then pass on the authenticated username in a header (e.g. X-Auth-User), which is a much simpler pattern than some other SSO solutions like OAUTH. It would be great if PhotoPrism could also support this in the new multi-user option, then for me Plus would be worthwhile. **Describe the solution you'd like** Implement authentication via a header from upstream proxy. The name of the header to check should be configurable, and users should still be created and managed via the admin UI. **Describe alternatives you've considered** If this is already the authentication used for other services (as in my case), implementing an alternative is not suitable. **Additional context** A couple of examples where this is implemented - Grafana, Calibre-Web. There are many more.

deekerman

2026-02-20 01:10:52 -05:00

closed this issue
added the
declined

idea
labels

deekerman commented

2026-02-20 01:10:53 -05:00

Author

Owner

@lastzero commented on GitHub (Aug 31, 2025):

Thanks for the suggestion! We won’t add authentication based on a plain X-Auth-User (or similar) header.

While convenient, trusting a username passed in a request header is very easy to misconfigure and can be spoofed if the trust boundary is not perfectly enforced end-to-end. It would also bypass core security controls like token scopes, session lifetimes, and (where enabled) 2FA, which is not acceptable for a multi-user app.

Supported approach: Please use standards-based SSO via OpenID Connect (OIDC), which PhotoPrism supports out of the box. Configure your identity provider (e.g. Keycloak, Authentik, etc.) and point PhotoPrism to it using the OIDC settings. For enterprise environments, PhotoPrism Pro additionally supports LDAP/AD.

OIDC & config options are documented in our docs and CLI flags.
Reverse proxies (Traefik/NGINX) remain fully supported for TLS, routing, and hardening, but authentication should terminate at the IdP, not be injected as a raw header.

Given the security risks and the existence of robust alternatives, we’re marking this not planned. If a widely adopted, signed upstream-identity standard becomes applicable without weakening our threat model, we can revisit.

@lastzero commented on GitHub (Aug 31, 2025): Thanks for the suggestion! We won’t add authentication based on a plain `X-Auth-User` (or similar) header. While convenient, trusting a username passed in a request header is very easy to misconfigure and can be spoofed if the trust boundary is not perfectly enforced end-to-end. It would also bypass core security controls like token scopes, session lifetimes, and (where enabled) 2FA, which is not acceptable for a multi-user app. Supported approach: Please use standards-based SSO via OpenID Connect (OIDC), which PhotoPrism supports out of the box. Configure your identity provider (e.g. Keycloak, Authentik, etc.) and point PhotoPrism to it using the OIDC settings. For enterprise environments, PhotoPrism Pro additionally supports LDAP/AD. - OIDC & config options are documented in our docs and CLI flags. - Reverse proxies (Traefik/NGINX) remain fully supported for TLS, routing, and hardening, but authentication should terminate at the IdP, not be injected as a raw header. Given the security risks and the existence of robust alternatives, we’re marking this not planned. If a widely adopted, signed upstream-identity standard becomes applicable without weakening our threat model, we can revisit.

deekerman commented

2026-02-20 01:10:54 -05:00

Author

Owner

@pseudocoder commented on GitHub (Aug 31, 2025):

Thanks for the reply, and of course it's your choice as to what to implement.

But your last statement is very dubious - I work in a highly regulated industry and our Nevis proxy uses exactly this mechanism for hundreds of secure applications (alongside more complicated options like JWT), so I would say this is a widely used defacto standard.

@pseudocoder commented on GitHub (Aug 31, 2025): Thanks for the reply, and of course it's your choice as to what to implement. But your last statement is very dubious - I work in a highly regulated industry and our Nevis proxy uses exactly this mechanism for hundreds of secure applications (alongside more complicated options like JWT), so I would say this is a widely used defacto standard.

deekerman commented

2026-02-20 01:10:54 -05:00

Author

Owner

@lastzero commented on GitHub (Aug 31, 2025):

Since our software is used by a wide range of individuals and organizations, we cannot make assumptions about its use in highly regulated environments where networks are well secured and all security settings are double-checked by professionals.

@lastzero commented on GitHub (Aug 31, 2025): Since our software is used by a wide range of individuals and organizations, we cannot make assumptions about its use in highly regulated environments where networks are well secured and all security settings are double-checked by professionals.

deekerman commented

2026-02-20 01:10:54 -05:00

Author

Owner

@pseudocoder commented on GitHub (Aug 31, 2025):

Also fair, but then you're making the assumption that the user doesn't know what they're doing rather than giving them the option.

But I don't want to waste your time on a long discussion, it isn't a big deal but for me it means I have two layers of authentication since I also don't directly trust the PhotoPrism login ;-) If it bothers me enough I'll set up OIDC, but ironically my work network seems to really dislike Keycloak's login flow and blocks it for security reasons LOL.

@pseudocoder commented on GitHub (Aug 31, 2025): Also fair, but then you're making the assumption that the user doesn't know what they're doing rather than giving them the option. But I don't want to waste your time on a long discussion, it isn't a big deal but for me it means I have two layers of authentication since I also don't directly trust the PhotoPrism login ;-) If it bothers me enough I'll set up OIDC, but ironically my work network seems to really dislike Keycloak's login flow and blocks it for security reasons LOL.