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.

[tpansino]

It looks like Header-based auth has been implemented as of v0.36.0 🎉

Note that if you are using Registry Mode to share your registry/wishlist out with a link so users don't have to have log in with an account to see it, and then you put your instance behind an authentication proxy to use Header-based auth, those shared links will start displaying a login screen for your auth proxy.

Fortunately, since Wishlist is using session cookies, you can configure your auth proxy to only protect the /login URL, and leave everything else unprotected. This will allow unauthenticated users to still use your shared links, and any attempts to access other paths will be redirected to /login, which should display a login page for your auth proxy.

Here's an example of how to do this with Authelia:

access_control:
  rules:
    - domain:
        - wishlist.example.com
      policy: two_factor
      subject:
        - user:tpansino
      resources:
        - '^/login(\?.+)?$'. # <-- Since Authelia does a full URL match, this regex covers URLs with a query string too, like /login?ref=/claim 
    - domain:
        - wishlist.example.com
      policy: bypass

[tpansino]

@cmintey let me know if my technique for fixing Registry Mode here is inaccurate or insecure with how you have the app configured for any reason? Like if there's any sensitive endpoints or routes that don't redirect to /login if the user doesn't have a session cookie, for instance.

This might also be good info to add to the Header auth section of the README, as anyone using Registry Mode and Header auth at the same time is going to hit this problem.

[cmintey]

Thanks for pointing that out! I think that strategy works great. Every page has an auth check (except for the public one) that redirects to the login page, so I see no issues.

In an upcoming release, I do plan on re-using that /lists URL to support the multiple lists features. But I will first check if the list is public before doing any auth checks, so I think this strategy will still work with that.

I can look to add this to the README, or you are welcome to open a PR as well