Feature Request: OAuth Login without Open Sign-up

With 0.12, writefreely supports OAuth login :partying_face:. However, this requires the server to have open registrations enabled (otherwise logging in via OAuth returns ‘This user does not exist’ error). While in theory this makes sense, it results in requiring the instance to accept email-based sign up as well as OAuth without being able to distinguish between the two.

I suggest changing the ‘Open Registration’ to ‘Open Local Registration’ and only allowing the ‘Sign Up’ link to show if it is set. If one of the OAuth log in methods are configured, create accounts for successful login without checking the ‘Open Local Registration’ configuration option.

You don’t have allow registrations - I’ve just checked the flow on fedi.dev: (built from develop branch + oauth-gitea) existing user logins with password, goes to Account Settings and links OAuth account (in my case - Gitea) - worked as charm :nerd_face:

Since there are no OAuth permission controls in WF right now, I had to implement a bit of a stopgap at the last minute. But it’s still possible to do this in v0.12!

To run your community with OAuth + closed registration, you can simply use the Invite feature. You’ll create an invite link (or many) from https://yourinstance.com/me/invites, and send it to the people you want to join. Then with OAuth configured, when a user visits the invite page, they’ll be able to click the OAuth option instead of email. Could you give that a shot and let me know if it works?

Beyond this, I agree we’ll want something like what you mention – the option to disable username-based signups but allow signups through trusted OAuth providers.

1 Like

You misunderstand the use-case - we would like to enable user registration through OAuth, but not usernamed-based ones. This is because we have a large GitLab instance (1000+ users) that we want to use as our source of truth for accounts, without needing to manually create each account for people who wish to use WriteFreely.

Thanks, I will test that. Long term, we would definitely prefer not having to invite people, as that will quickly get out of control. But for the moment that should work.

1 Like

I’d definitely like to support that, too.

The key issue to address is the different kinds of user limitations each OAuth platform and instance offers. E.g. whereas your GitLab instance only has users you’d trust on WF, other instances like gitlab.com include untrusted users. Registration settings will differ widely based on how an admin has everything setup.

I could imagine one simple way forward with this: adding an open_registration flag to each individual OAuth provider in the configuration. If true, it would allow new users through that provider, regardless of the instance-level setting. That could allow granular control over registration that should fit a wide array of setups.

Good point. I had not considered that. Your suggested solution would work for us.

P.S. please enable email replies to threads in Discourse

Great to know that would work for you :+1: I think we’ll go in that direction then.

And great suggestion – you should be able to reply to threads via email now.