You can have user accounts without needing to manage user accounts

The inimitable Simon Willison has a brilliant presentation all about managing side projects:

It is all good advice. But I gently disagree with the slide which says:

Avoid side projects with user accounts If it has user accounts it’s not a side-project, it’s an unpaid job

I get the sentiment. Storing passwords securely is hard. Dealing with users changing their names is hard. Updating avatars is hard. GDPR is hard. It's just a lot of pain and suffering.

But I still have user accounts on one of my side projects while avoiding all those issues. Here's how it works on OpenBenches.

Use Auth0

The Auth0 service is a multi-vendor OAuth provider. That means I can offer a button which "login" which leads to this screen:

Auth0 has around 60 different social login providers. I picked the ones which best suited my users' demographic.

So the user hits "Sign In With Twitter⁰", gives Twitter their username, password, blood sample, and 2FA token. Twitter gives OpenBenches an authentication token with read only access.

This is important. Even if I were hacked and the tokens stolen, an attacker wouldn't be able to alter the user's account on a different platform.

But, as it is, I don't store the token. So it can't be stolen.

Only store the essentials

Here's the database which contains my user "accounts":

 SQLCREATE TABLE `users` (

  `userID` BIGINT(20) NOT NULL,

  `provider` VARCHAR(64) COLLATE utf8mb4_unicode_ci NOT NULL,

  `providerID` VARCHAR(64) COLLATE utf8mb4_unicode_ci NOT NULL,

  `name` VARCHAR(128) COLLATE utf8mb4_unicode_ci NOT NULL

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

The userID is just an internally-used key which is incremented. I guess it could be a GUID or something.

The provider is a string like twitter or facebook or linkedin etc.

The providerID is the publicly available ID assigned by the social login service. Twitter gives everyone a number, LinkedIn gives everyone a random string, etc.

The name is the string that the provider calls you. My Twitter name is @edent and my LinkedIn name is Thought Leader Terence Eden.

That's it! I don't store any access tokens. I don't store a date of birth. I don't store any data unnecessary to running my project.

What about updates?

I don't store URls to avatar images. Instead, I use Cloudinary's Social Avatar service. That's usually as simple as calling res.cloudinary.com/demo/image/twitter/1330457336.jpg - I have to fuss around a little for GitHub and Facebook. So as soon as the user changes their avatar with their provider, it changes on my site.

Sometimes people change their names. Every time they log in to OpenBenches, I check to see if their name has changed - and update it if it has.

Most services don't let you change your internal ID. So that's fixed.

Where it goes wrong

It isn't all sunshine and roses though. Here are two things which might give you cause for concern.

What if a user wants to merge their accounts? On OpenBenches we sometimes get users who set up two accounts - and then want data from each of them merged. So far, my answer has just been "no".

What if a user wants to delete their account? Well, they can delete it with Twitter or whoever. If someone asked, I'd probably delete their username from the table. But it hasn't happened yet.

Should you do this?

I'm not your real dad. It isn't my job to tell you how to live your life or set up your side projects.

Generally speaking, user accounts are bad news. We resisted having them on OpenBenches for the longest time - people were anonymous. But we had lots of users who wanted a leader board so they could show off how many benches they had uploaded. The only way we could build that is with user accounts. So we added it. You can see the Leader Board in action.

Building side projects can be a bit lonely. So it is sometimes nice to develop a community of people who want to use your stuff.