alt.hn

7/31/2026 at 2:17:43 PM

Authorize, don't authenticate

 https://blog.marcua.net/2026/07/31/authorize-dont-authenticate.html

by marcua

8/1/2026 at 3:18:36 AM

(c.f. other comments about confusing misuse of security terminology)

An easy way to remember the difference between the As in AAA:

    Who is your daddy, and what does he do?
    ^ authentication       ^ authorisation
And the all too often forgotten final A is accounting, for which you can imagine Arnold writing down the interaction in his police notepad.

:-)

by jdub

8/1/2026 at 4:56:00 AM

Simplified:

    Who are you and what do you want?

by noisy_boy

8/1/2026 at 7:40:59 AM

Doesn't sound nearly as good in the original Austrian (accent).

by jdub

8/3/2026 at 4:54:18 AM

authenticate: who are you?

authorize: what do you want?

account/audit: what did you do?

by syngrog66

8/1/2026 at 7:14:14 AM

Vorlons authenticate, Shadows authorize

by tomkarho

8/2/2026 at 10:36:06 PM

ah, the tragic truth of there being no daddy at all alive. alice bawled.

by jambalaya8

8/2/2026 at 10:39:10 PM

[dead]

by cindyllm

8/1/2026 at 3:37:45 PM

ah, but the confusion in the security model of a more-than-one-daddy family.

by jambalaya8

8/1/2026 at 9:53:38 AM

I have shitty memory and never confused those... something else is amiss here

by pestatije

8/1/2026 at 6:59:24 AM

It seems like your unnecessarily kinky mnemonic also forgot the third "A". Don't mnemonics usually cover the entire list of the thing you want to remember?

by ButlerianJihad

8/1/2026 at 7:15:59 AM

It’s a memorable quote from the movie Kindergarten Cop.

by williamcotton

8/1/2026 at 8:21:08 AM

They didn’t call it a mnemonic. They are suggesting recalling a movie scene to remember AAA. And imo, it’s a great one that I’ll be reusing to help others remember! I have to remind folks of the difference frequently at work.

by simonjgreen

7/31/2026 at 10:45:40 PM

Got drawn to the topic, however usage of authentication and authorization seem like misnomer here, the core topic seems to be data ownership

The concept on a surface level to have ownership over the data makes a lot of sense and to a large part the support exists in a fragmented manner across the different providers/applications.

The concrete idea of user having a database and then authorizing that to the service is highly impractical. It might be applied for experimentation purposes in highly controlled environment but cant scale beyond that.

1. Databases require maintenance, backups, failover

2. Schema update are nightmares. No one is ever comfortable with it, specially the bigger you are.

3. Authorization seems to be following one to many pattern here, one database and multiple applications. Its a no go in case of update operations

by sandeepkd

8/1/2026 at 12:24:08 AM

Yes, it still does authentication. It's just about hosting the data, which might make sense for niche scenarios with well defined scope. Unfortunately, many data-driven systems need some kind of data sharing. Relying on data from multiple custodians is possible and could be cool but brittle if a single view is pulling data from many custodians. Also it would be impossible to run meaningful analytics on such scattered data... I guess that could be seen as a feature.

I think this may end up happening naturally over the next decade or so thanks to AI coding. People will just stick web components bound to different data sources on the same page without even realizing it. Data can be joined and chained together on the frontend. Some shared authentication standard like JWT with asymmetric key signatures could potentially facilitate that. Multiple data custodians could verify the same JWT using the user's public key... Account could be hosted on some blockchain so it's not centralized.

by socketcluster

8/1/2026 at 12:57:38 AM

It might be helpful here to categorize the data as sensitive, personal, financial, chat, public comments as such and then apply the probability model on a given category. I would probably call the AI coding as misnomer too, what you have is a higher level of auto complete functions and natural language processing.

Theoretically even I love the idea of independence, however practicality of such a thing has to be evaluated. From all the examples that exists as of today, a true and meaningful decentralization is not viable in the absence of a a trusted centralized component.

by sandeepkd

8/1/2026 at 3:04:59 AM

(Author here)

Thank you for pushing on this. Some clarifications that might help you see this as more practical than your initial impression: * I totally agree that databases require maintenance, HA, etc. My argument is not that someone running a database magically doesn't have to do these things, but rather that the person running the database doesn't have to be the person running the app. In the video attached to the blog post, you can see that separation in action: marcua.net hosts the Todos app, but thedata.zone hosts an ayb [1] database instance. As the owner of thedata.zone, it's my responsibility to configure the database for stuff like offsite snapshot-based backups (which I've done). * Schema migrations are an application-level concern, and are no more or less challenging in the model I'm proposing. As a convenience, in the ayb.js client I open sourced, I add some utilities for forward-only migrations to make it a little easier for application developers who build around ayb to have migrations fire at the right moment in their application's lifecycle. * Authorization is definitely not assumed to be one database to many apps. In the video, look for how the user already has a streaks.sqlite database (for storing streak data) and creates a new todos.sqlite database for storing their to-dos.

Thank you for engaging on this! I look forward to hearing your thoughts!

[1] https://github.com/marcua/ayb

by marcua

8/1/2026 at 5:51:31 AM

For the sake of discussion lets leave the business aspect. What you are offering is a service for managed database, similar to lot of cloud providers. What you have on the top of it is a OAuth2 process to obtain relevant credentials.

From practical standpoint you have to consider that the traditional use case for databases has been N:1 (n application instances, 1 DB) and you are inverting this.

There might be some unique B2C scenario where this makes business sense, however if you are providing database service then I cannot see how this would be any different.

On a side note, there are quite a number of B2B scenario where the client provides the DB for data residency requirements and the service providers uses that DB to manage the data on behalf of the client.

The price is also a big concern, a user scope database is going to be quite costly, as a provider you would end up sharing the infrastructure

Lastly I will repeat it again, schema migrations are as much as database level concern, and migrating N databases above a certain scale is not easy.

by sandeepkd

7/31/2026 at 10:48:54 PM

yeah the article is dumb.

by zobzu

7/31/2026 at 9:50:35 PM

So many tools and libraries combine authorization and authentication, and it’s hard to find an authorization server that lets you outsource identity.

(All too often the underspecified abbreviation “auth” is used to cover both.)

Shameless plug: My colleagues and I implemented a minimal authorization server that lets you leverage a trusted identity provider of your choice (like Entra ID or even Auth0/Okta) and handle authorization. It looks up what roles and permissions the identified user should be able to have/grant and issues tokens containing that authorization.

https://github.com/DMGT-TECH/the-usher-server

by pakl

7/31/2026 at 10:24:27 PM

Nice! If it works with Authelia (or Authentik) too then I'm sold. Thanks for sharing.

by aquariusDue

7/31/2026 at 9:09:25 PM

We are back to File->Open I guess. We could use native applications instead of web apps while we're at it.

Sadly this approach does not work for a lot of (web) apps.

by _def

8/1/2026 at 3:17:03 AM

Author here!

The solution I'm proposing does not assume the data is local to the user's machine. In the video attached to the blog post, a web application is authorized to access a database hosted by a different service/domain. While the blog post covers collaboration/social data as current limitations, I'm curious what other classes of web apps you think don't work with the proposed approach?

by marcua

8/2/2026 at 7:08:24 PM

If the database is not local, and there’s no authentication, what stops someone else from accessing it inappropriately?

by jmsgwd

7/31/2026 at 10:32:29 PM

yeah, to me this also pretty much sounds like the approach we started with, we bring our data (as a file) into the application and it stores it back if we want to.

by mqus

8/1/2026 at 6:25:32 AM

Everything old is new again. We started with timeshare machines (there is only market for 7 computers in the world) where you accessed with VT102 etc terminals.

Then we went to personal computers with local data and code.

Now we are back to a handful of massive timeshare machines (AWS, Azure, ..) that keep your data and let you only access with HTTP/HTML terminals.

Now if people get angry enough with Salas enshittification we'll go back to personal computers again...

by happosai

7/31/2026 at 9:33:33 PM

1. How do you get around performance issues? If I have a difficult join and you have a slow database, or you have a flaky connection, how can I debug the problem on my end?

2. What stops me (or any attacker) from exploiting your lack of security? Are you 100% sure you are secure?

3. You mention collaboration - How does this work at a company level if we have many users and need to control access - the company is the entity with rights to the data in this case.

by ebiester

8/1/2026 at 3:33:19 AM

Author here.

Thank you for your questions. I'll take a stab at answering them: * The underlying databases that ayb fronts are SQLite and DuckDB. Both are relatively battle-hardened RDMBSs. That said, I don't think the approach I'm proposing has any bearing on the difficulty of a query: if a centralized DB would struggle with a query workload, the personal DB is likely to as well. One saving grace is that workloads are slightly more isolated in my approach: someone else's data that's poorly shaped for a query shouldn't affect your queries, which is not something most all-users-in-the-same-database approaches can claim. * I make no special security claims beyond what is listed in the documentation [1]. ayb specifically has been used in production by low single digit numbers of people, so you should absolutely wait to use it for any super-sensitive data, especially in a shared/multi-tenant context. That said, you should be no more confident in the random web app that stores your data for you than you are in ayb's security. * This blog post is focused on personal data: the to-do list, the streaks/goals you've set out for yourself, your database of newsletter subscribers. I think there's some interesting work to be done in the enterprise around access control. In ayb, there are coarse-grained sharing/permissions [2], but I don't think that's enough for most enterprise situations.

[1] https://github.com/marcua/ayb#isolation [2] https://github.com/marcua/ayb#permissions

by marcua

7/31/2026 at 11:52:08 PM

I've been hacking on my own task manager on-and-off for years (https://the.do.zone). It has no database; the primary store is the browser, and you can optionally sync to local file system (if using chrome), dropbox, or google drive (less optimal for my needs, because their js oauth implementation is very conservative about token length.) It has some crude but functional diff resolution, so that you can sync across multiple machines. Browsers _could_ provide better tooling to make this kind of app architecture more convenient to write; and theoretically you could imagine cloud providers providing some kind of standard for datastores. But there's no market for it; non techies really don't care about the location of their data to any great extent.

by smallerfish

8/1/2026 at 1:02:10 AM

They do care, but not at the right point in the sales cycle. They care about the eventual bait and switch. They care about how in the face of that pack of lies they can't even recover their own data in any capacity whatsoever. They just don't recognize ahead of time that data location is a critical ingredient in preventing recurring pains they definitely know and understand.

by hansvm

8/1/2026 at 10:49:25 AM

I really like this concept (though the post is terribly named as others have said). "Databases that are easy to make as documents" is so obvious that you wonder why it isn't more of a thing. Add in "untitled" databases that live in a session/browser so you can "try before you buy", maybe the option for single file databases with no intermediary/service (so you have a Databases folder that is as messy as your Downloads folder... but is that really so bad? better than a password manager full of garbage services IMO), and you basically get EASY seperation between application and data, which is Good for a lot of reasons (lock-in, ownership etc)

by explodingwaffle

7/31/2026 at 9:31:33 PM

Not sure this does anything for data portability, since apps will just store the data as encrypted & signed BLOBs.

by warkdarrior

8/1/2026 at 2:21:21 AM

I feel like this blends two discrete things

1. Can I have access to my data (the side effects of my interaction with an application) in a portable way?

2. Can I stop or prevent others (like the application author) from having access to my data?

I wonder which -- if users had to choose -- they care more about? I think for most uses its #1 unless its very personal data, in which its #2. I love the idea as presented in this article but I'm not so sure how practical it is. I don't know how much overlap there is between "author has to run application a central server" (can't just be a local app) and "author must not retain data".

Seems like a really awkward space to inhabit.

by hankbond

8/1/2026 at 3:13:02 AM

(Author here)

Hello there! I agree users may want one or both of these features in their interaction with an application, and that their preferences likely vary depending on the type of data we're considering. The way I'm reading what you're saying, there's some sort of tension or tradeoff between the two features that I don't fully understand. Can you help me understand it a bit better? Thank you!

by marcua

8/2/2026 at 3:40:07 PM

Well for instance the approach that was demonstrated (as I understood it) seems to necessitate a lot of tradeoffs and maybe concessions in app design to meet the authorize criteria. Is it accurate to say that all data provided to the service is stored and operated on locally? I don't know how I would do something like a scheduled notification with that setup unless that too is locally executed (in which case it's all just an app?).

I was thinking more along the lines of how I want the ability to export my data into something machine readable, and then delete it from the server. This allows for most conveniences and flexibility on the authors part to be available, but still provides the user with control over the data.

I think I just wanted to communicate that on the spectrum between no ownership and what your approach proposes, I'm less of a maximalist.

Thank you for the piece and the reply.

by hankbond

8/1/2026 at 2:07:05 AM

If people manage their own data, that essentially means each person has their own database. And a database has to be connected to an application. Whenever the database schema changes, the application's CRUD operations have to be updated as well.

In the end, it seems likely that everyone will develop and maintain their own web application, and if others need access to their data, they'll expose it through APIs.

by sqemo

8/1/2026 at 9:06:30 AM

The idea of apps accessing a database directly instead of going through an API keeps popping up every few years. It never works. And the reason is exactly about authorization. Google CouchApps and read the post they wrote about why doing that is a very bad idea, despite sounding awesome without spending too much thought on it.

by brabel

8/1/2026 at 6:56:00 AM

Absolutely. A service has no business to know who you are. They should only care if the user has authorization.

Authentication has historical reasons. Employee access, citizen services etc all are identity based. Identity was translated into authorisation for multiple services instead of each service requiring it's own authorisation.

by zkmon

8/1/2026 at 1:46:27 AM

> It’s your data! You shouldn’t have to prove to anyone else that you have the right to access it.

How does the service know who you are? That's the point of authentication. Once that question is settled, the service can decide what you are authorized to do. You need both.

by esafak

8/1/2026 at 3:36:50 AM

Author here!

Thank you for asking. It's a difficult concept to wrap one's head around, but I think the video attached to the blog post shows it most clearly. There's no authentication with the application in the traditional sense, and the application never asks for your identity. You ARE authenticated with the database provider (ayb's thedata.zone in the video), which passes a token to the application so that the app can prove it has been authorized to access the database on future requests.

by marcua

8/1/2026 at 3:55:42 AM

I remember all the confusion when I was first learning secure connection stuff, like ssl

Because when I saw "auth" ... was it authentication or authorization?

by m463

8/1/2026 at 9:04:18 AM

Good idea, but how is it supposed to be practical for non-technical users?

by jdthedisciple

8/2/2026 at 3:30:17 AM

and if youre a technical user, how is it not redundant

by dspnc

7/31/2026 at 11:49:12 PM

Isn't this the core idea behind atproto?

by ashleyn