Support for external auth/identity providers

[tpansino]

This is a BIG ask for a single-person project, but I wanted to capture it anyway, because I see it requested frequently for similar projects.

As an admin
I want to be able to connect Wishlist with my external auth or identity provider (eg: Keycloak, Authelia, Authentik)
So that I don't have to explicitly invite users to join my instance
And so that I can manage their access centrally.

As a user
I want to be able to log into Wishlist via an existing login (SSO)
So that I don't have to manage yet another password.

The two primary methods I have seen implemented on similar projects:

1. Support for OIDC-based login. This tends to be a route only larger projects take due to flexibility it provides, at the cost of a LOT of additional code complexity. If you're using a framework like Django or Nest.js though it can be relatively easy to add this functionality via plugins in those ecosystems, or something like Passport.js. If you do go this route, it should satisfy any and all requests to support big identity providers like Google, Facebook, Apple, as well as self-hosted ones like Authelia, Authentik, Keycloak, and many others.
2. Support for header-based auth, also known as Forward Auth. This typically involves the admin fronting the application with a reverse proxy (eg: Traefik, Caddy) that forwards incoming packets first to a separate auth service that supports Forward Auth mechanics (eg: Authelia, Authentik). The auth service then fully handles user authentication and authorization, after which the reverse proxy sets specific headers on the request (eg for Authelia: Remote-Name: T Pansino, Remote-Email: tpansino@example.com, Remote-User: tpansino) before the request reaches the application server. The application then just reads the username/email/name from each inbound request and trusts that the auth service did its job and that the request was sent by that user. This is often a LOT simpler to implement than OIDC because it only requires typically some middleware in your application to check the request for these headers. If you go this route - note that the middleware MUST check that the admin has actually enabled Forward Auth in the application settings first (otherwise an attacker can send a request with the headers already set, and the application will just trust it). It's also a good feature to allow the user to define the name of the header(s) the application reads from for username, email, etc, on the settings page because there isn't a clear standard for these header names and every reverse proxy uses different ones in my experience. Finally, you'll need to have the middleware handle automatically creating an account for a given username if they've never logged in before.

Definitely a bigger project to implement this, and I'm personally not expecting to see progress anytime soon - if ever! :) But hopefully this helps if you ever do decide to implement it.

Happy to answer any questions as needed, and thanks again for your efforts.