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:

Login page with buttons for Facebook, Twitter, WordPress, GitHub, and LinkedIn.

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 Twitter1", 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":

CREATE 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 - 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.

  1. This blog post was written before Alan turned off the 2FA from Twitter. Then turned it back on. Then fired everyone. Then rehired them. Then whined about how much food they ate. Anyway, I've left Twitter. Come join me on Mastodon

Share this post on…

7 thoughts on “You can have user accounts without needing to manage user accounts”

  1. said on

    @Edent There's a lot I don't like about Gemini but something I do like, at least in principle as I haven't used it in practice, is the use of client-side certificates (or just key pairs?) for identity. Obviously, that's possible with HTTPS as well but I don't think either standard browsers or web servers make it easy which is a great pity.

    Reply | Reply to original comment on
  2. said on

    @Edent Yes, but...This is forcing the users to tell one of the big guys that they are using so and so app. You can't split identities per service if you have to identify through another one.This is what Tailscale is doing, and while I do understand the reasons, I don't agree. Just hide the local account option somewhere, so it is not the default.But that's just my view on this.

    Reply | Reply to original comment on

Trackbacks and Pingbacks

  1. Auf einer Präsentation von Simon Willison gab es auf einem Slide das folgende, hier gekürzte, Statement zu lesen:

    Avoid side projects with user accounts. If you build something that people can sign into, that’s not a side-project, it’s an unpaid job. It’s a very big responsibility, avoid at all costs!
    Simon Willison

    Das Statement ist komplett aus dem Zusammenhang der Präsentation gerissen (es geht hier eigentlich um Nebenprojekte), hat mir aber eine Sache verdeutlicht: Projekte mit User-Accounts sind keine „Projekte“ mehr, sondern Jobs. Und das stimmt auf jeden Fall nicht nur für Nebenprojekte, sondern auch für ganz reguläre Aufträge und Projekte. (Eine Gegenposition dazu gibt es auf Terence Edens Blog, über den ich überhaupt auf die Präsentation von Simon Willison gestoßen bin.)
    Es gibt, sofern das Projekt Dritten gegenüber offene User-Accounts unterstützt, immer und immer wieder mal de facto Supportanfragen, die vom Auftraggeber oder der Auftraggeberin „durchgereicht“ werden, weil er oder sie sich schlichtweg mit dem spezifischen Fehler nicht klarkommt oder das Problem mit dem ihm oder ihr zur Verfügung stehenden Mitteln nicht (ohne Risiko) beheben kann. Bei solchen Projekten wird man also zu einem versteckten Dienstleister für Supportanfragen Dritter.
    Mehr habe ich dazu nicht zu sagen. Aber verdeutlicht musste es im Sinne des Denkens durch Schreiben mal werden.

What are your reckons?

All comments are moderated and may not be published immediately. Your email address will not be published.Allowed HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <p> <pre> <br> <img src="" alt="" title="" srcset="">