Support more auth methods, besides username+password

[tmaier]

Requests like #336, #333 will come up with requirements to support other means to authenticate besides username+password. Read: SSO to support "business" use cases (e.g. using generic oAuth 2, EntraID, Google SSO)

In my case to self-host applications like hostedgpt, I tend to use a "ZeroTrust" approach, where the application is not exposed to the public internet. ZeroTrust approaches, like with Tailscale ensure authentication of a user already on the infrastructure level. So no need to re-authenticate the user.

To support SSO, there are two ways to implement it:

1. Add support to omniauth and support with this a random set of SSO providers. This is a maintenance hell for this proejct
2. Allow to skip username+auth and allow to conduct authentication using a HTTP header. This outsources the authenticaton logic to 3rd party services. This is what I would recommend

Deep dive in auth via HTTP header

A 3rd party service (e.g. a reverse proxy or a ZeroTrust appliance) would set a header, which if it exists means the user has been authenticated.

This is supported by Reverse Proxies like Traefik (see for example BasicAuth and especially ForwardAuth where they support a 3rd party auth server), Caddy with forward_auth, Nginx with auth_request_set (source: blog post)

ZeroTrust services like Tailscale can be used with $ tailscale serve. Tailscale sets in such a case so called "Identity headers" (ref. https://tailscale.com/kb/1312/serve?q=header#identity-headers)

The key is: the name of the "identity headers" is not standardized. It would need to be exposed as a configuration setting (e.g., environment variable).

Example: Paperless (a self-hosted DMS) allows to enable authentication via "HTTP_REMOTE_USER" via the setting PAPERLESS_ENABLE_HTTP_REMOTE_USER_API (boolean). The name of the header can be set via PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME. I think this is related to a default feature of Django (ref. https://docs.djangoproject.com/en/5.0/howto/auth-remote-user/).

Possible approach to support this in Rails / hostedgpt

1. A password must not need to be mandatory at the User model. Ref. https://github.com/allyourbot/hostedgpt/blob/0.6/app/models/user.rb#L7
2. The Authenticate concern would neither set nor read session[:current_user_id]. Instead, it would look at the defined HTTP header in each request. Ref. https://github.com/allyourbot/hostedgpt/blob/0.6/app/controllers/concerns/authenticate.rb#L11-L16

[krschacht]

Yea this is a good thread to bring up. I’m thinking along similar lines but I think we could do a bit more than that.

I’m definitely in favor of writing the auth rather than using Devise. I’m trying to avoid big dependencies with his app and so far it’s been working well.

The current auth is really a super basic v1. One of our contributors implemented it and it’s served us well so far, but we’re just about ready for something more robust. I have a decent v2 authentication that I’ve implemented in another rails app that I could adapt; I also have a copy of the Campfire code that I was going to inspect for any inspiration. But I also wanted to take a closer look at https://github.com/lazaronixon/authentication-zero

This seems like a really nice approach since Rails 8 auth generator is not out yet, and likely this will include a bunch of features that Rails 8 generator won’t.

I think some of the most important things to add to auth soon are:

• Auth via HTTP header
• Basic email verification during signup (just email format)
• Password reset via email
• Google Auth login

I think email+password, HTTP header, and Google Auth should be enough for the foreseeable future. I wouldn’t try to support any other Oauth providers besides Google, but I do think that single one is worth the effort. It looks like authentication-zero also uses OmniAuth (which I’m not too familiar with).

@tmaier Would you be up for tackling any of this? I could really use someone to take the lead on this, and I can help with code review and some of the implementation details.

[tmaier]

I fully agree on not using devise. It is too large and gets complicated easily.

So one could break it up like this:

1. Refactor/improve username+password
   • Add basic email validation (upon registration)
   • password reset capability
   • Since people self-host this, they may also want to limit the domain allowed to register (e.g., just users from @example.com)
2. Add support to externalize authentication via HTTP header
3. Support Google Authentication
4. Figure out / document how to provide global configuration. (e.g., env variables vs. Feature model)

I think I could add support for (2), since I thought through it already and it is fairly trivial.

I also implemented (3) recently in one of my personal projects. Here I did not use devise, but omniauth. This would mean an additional dependency on the omniauth-google-oauth2 gem.

I could not promise a deadline, due to personal constraints.

[krschacht]

Taking on (2) and (3) sounds great, it makes sense to use OmniAuth. It’s pretty light and standard. I’m flexible on timing.

Make a quick comment on:
#340
#339

I can’t assign to you until you comment, for some odd github reason

[tmaier]

Alright. I would you to provide guidance on (4)

[krschacht]

What kind of global configuration are you thinking of? So far the only item we’ve had (DEV_SERVER) made sense for ENV. I’m not sure what the next item of config will be. I guess what you just proposed, limiting sign-ups to a specific email domain, might be one example.

Visually, here’s what I think. On the /settings route we current have assistants and one link to “Account”. Maybe we add one new section called “System” and this is where we store system-wide settings. While we’re at it, we should have an “admin” boolean on the User table and then the first user who ever registers gets this set to true and then admins have the ability to give other users admin ability.

On the System page, I don’t know where we save that. It feels odd to create a whole ActiveRecord model just to have a single record within it with a “properties” json column or something. I’ll think more about this… There’s probably a better pattern. I might check the Campfire source code I bought to see how they do it.