Authorize, don’t authenticate | N=1 (marcua’s blog)

The login screen of any web application is the equivalent of that application telling you “In order to access YOUR data in MY database, prove you are who you say you are.” You’re authenticating with the application so that you can have the privilege of giving it your data.

In a previous blog post, I covered the downside to applications controlling your data. An application’s owner can restrict your access to your own data. They can delete the data. They can sell the data to a third party. They might introduce a bug that allows other people to access the data. They might get compromised. Or they can avoid all of this just to modify their policies down the road or see changes in ownership or management.

Subscribe

In a word: poppycock. It’s your data! You shouldn’t have to prove to anyone else that you have the right to access it. No one should tell you how to use your own data. And no one should do anything with your data that you aren’t comfortable with.

To gain agency over your data, you have to have agency over the database in which it lives1. If you own the database, you actually own the data. But running a database is a serious undertaking that we can’t expect from the average internet user. And even if you run a personal database, how should applications interact with it?

Over the past few months, I’ve explored the concept of personal database authorization, which allows you to give an application access to a database you control. Specifically, I built an authorization flow into ayb, my project to make it easy to create databases, share them with collaborators, and query them from anywhere. Here’s a video of how you can grant an application access to a freshly created database you own. Critically, the application has no login screen, instead asking for a database where your data will live:

Authorization in action: A to-do application with no login screen that requests access to a database you control. Todos is the to-do list application I created and use as my daily driver.

Holding on to your data

Here are three principles behind what’s happening in the video:

Authorize, don’t authenticate. In traditional web applications, you authenticate with the application to log in/prove your identity. Only once you’ve proved yourself with a password/passkey/… can you get access to your data. That puts the application in charge of your data. Instead, you should authorize an application to get access to your personal database. In the video, you see Todos asking you to Connect your database (“authorize me!”) rather than Enter your password (“authenticate yourself!”). The technology to support this flow is well understood and widely used: Todos initiates an OAuth2 flow to ask ayb for a token with which to query a database. I’ve open sourced an ayb.js library that manages these OAuth2 interactions on behalf of an application, and an engineer can integrate it into a new application in under an hour.

Creating a database should be as easy as creating a document. Most users can open up Microsoft Word or Google Drive and create an empty document. On the other hand, most users don’t know how to set up a Postgres database that backs itself up periodically and can be connected to a running application. In the video, the authorization flow allows you to pick an existing database or create a new one, and creating a new database is as easy as picking a name for it. If you create a database, you’ll receive periodic snapshots/backups without any configuration, and the application knows how to speak with ayb, run migrations, and store data in it. The database creation flow is no more difficult than one to create a file on your computer or the cloud, which is a lot more than you can say for most databases today.

Applications should store as little as possible outside a user’s database. The Todos application in the video is static HTML, CSS, and JavaScript. It knows nothing about its visitors. I assume somewhere in my server logs I can find the IP address of anyone that downloads the static resource, but beyond that, the application stores no state on my servers. For added privacy, you can download a self-contained index.html file and self-host the application. When you first load Todos, it asks you to Connect to your database to get started. Once it has a token with which to query your database2, all of your intimate to-do list items are stored in that database you own. You can revoke Todos’ access any time.

Trusting your host

Having just celebrated the virtues of storing data in a database you control, I have to deflate the balloon a bit. So far, I effectively said “don’t store your data with someone else, store it in something called ayb.” ayb is open source and while you CAN host it for yourself, do you want to? I believe ayb is pretty easy to install and run, but I certainly don’t think every user should become a database administrator. This leaves users with a...