Earlier today, I created a Forgejo instance for the t/suki community. I would like it if anyone with an account on the t/suki forum could automatically have access to Forgejo, so I need to figure out some way to do identity management/authentication.

It seems like there are three ways to solve the problem:

1. ⭐ Use Discourse as an OpenID provider. My favorite choice. In this situation, you would only have one account, and that would be your Discourse account. t/suki is focused on the community aspect, and I feel comfortable betting that Discourse will be core service that is important to its operation. Forgejo would delegate user registration to Discourse.

   Unfortunately, Discourse doesn’t support being an OpenID provider officially. However, there is a way to do this with an unofficial third-party server called distrust. On the bright side, Discourse staff said that such a feature would be a desirable addition to the official Discourse client and distrust appears to still be actively maintained. However, this thread is from 2021 and it appears that Discourse has not bothered adding support for becoming an OpenID provider and I am not aware of how trustworthy the developers of distrust are.

2. 👌 Offload identity management from Discourse to a different service. This choice is okay. In this situation, you would have one account managed by some other identity provider (like Keycloak). Forgejo and Discourse would delegate user registration to the identity provider. Imagine logging into Google, and having access to all of the various Google services like YouTube, Google Docs, and etc without having to log in every time you visit a new service that Google provides.

   However, it appears that Discourse didn’t implement a standard protocol for this. Instead, they made their own custom protocol called DiscourseConnect. DiscourseConnect is not OAuth2. This means that even if I wanted to use something like Keycloak which supports many standard protocols for managing accounts, I would need to pull in some unofficial third-party code to support DiscourseConnect like keycloak-discourse. I would also need to run another server to provide the identity service and migrate user accounts from Discourse to the identity service.

3. 😦 Use another service just for authentication. This choice sucks. In this situation, you have three accounts. You have one at an identity service which is used to authenticate, but authenticating only grants you permission to create accounts on Forgejo and Discourse. Imagine using your Google account to log into some other website that isn’t run by Google.

   The one benefit of this approach is that it would work out of the box as the software currently exists right now. However, as far as I can tell I would no longer be able to keep t/suki invite only, because that functionality is built into Discourse and not in something like Keycloak. Instead, I’d have to create every account manually in Keycloak or open registration to the public. I would also need to migrate user accounts from Discourse to Keycloak. I think any user could also, at any time, break the connection to the identity provider to turn their account on either service into a standalone one with a username and password. I’m not 100% sure about that though.

In my opinion, automatically granting access if you have an account at t/suki is vitally important, but I also don’t think any of these options are acceptable. Obviously, I think the first option is the best, but I do not relish the idea of running some code which is responsible for handling authentication that is made by unknown entities.

Also posted on t/suki