--- title: "Authorize, don't authenticate" url: https://daily.dev/posts/authorize-don-t-authenticate-7nbekvqkx source_url: https://blog.marcua.net/2026/07/31/authorize-dont-authenticate.html type: article source: "Hacker News" published: 2026-08-01T00:02:52.755Z updated: 2026-08-01T07:48:07.067Z tags: ["authorization", "sqlite", "local-first"] reading_time: 10 upvotes: 0 comments: 1 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Authorize, don't authenticate **[Hacker News](https://daily.dev/sources/hn)** · 10 min read · 0 upvotes · 1 comments ## Summary A developer argues for flipping the traditional authentication model: instead of users proving identity to an application that owns their data, applications should request authorization to access a user-controlled database. The author built this into 'ayb', an open-source project that makes spinning up personal SQLite/DuckDB databases easy. Using OAuth2 with PKCE, static web apps can request a token to read/write a user's own database with no login screen. The post covers three principles: authorize instead of authenticate, make database creation as easy as creating a document, and minimize server-side state. Limitations around collaborative and social data are acknowledged, and connections to local-first, ActivityPub, and AT Protocol are explored. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 1 discussion and 46 comments across hackernews (as of 2026-08-01). **TL;DR:** The community is skeptical of the article's framing (misuse of authentication/authorization terminology, conflation with data ownership) and doubts the practical scalability of user-owned databases, though the author's active engagement clarifies some misconceptions and earns partial credit for the concept. **Sentiment:** 25% positive · 50% mixed · 25% skeptical **The case for** - The idea of separating the database host from the application host is conceptually appealing and has precedent in B2B data-residency scenarios. - Isolating per-user workloads could prevent noisy-neighbor query performance issues common in shared databases. - The concept resonates with a broader trend of users wanting portability and control over their own data. **The pushback** - User-owned databases face serious practical hurdles: maintenance, backups, failover, and schema migrations across N databases at scale. - The article misuses 'authentication' and 'authorization' terminology, obscuring the actual topic of data ownership. - Collaboration and multi-user/enterprise access control are largely unsolved in the proposed model. - Analytics on scattered, user-hosted data would be extremely difficult or impossible. - Non-technical users generally don't care about data location until it's too late, limiting real-world adoption. - Apps could simply store data as encrypted BLOBs, defeating any portability benefit. **By community** - hackernews (skeptical): Commenters broadly question the practical viability of user-owned databases and criticize the article's confused use of security terminology, though the author's direct responses soften some criticism. **Hottest debate:** Whether user-owned/hosted databases can realistically scale given schema migration complexity, maintenance burden, and the N-databases-per-app inversion of the traditional N-app-to-1-DB model. **Open questions** - How would meaningful analytics or cross-user queries work on data scattered across individually hosted databases? - How does the model handle enterprise/multi-user access control beyond coarse-grained permissions? - Is this conceptually equivalent to existing protocols like atproto, and if so, what does it add? - Who is responsible for database security and uptime when the user is the custodian but lacks technical expertise? **Highlights** > 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 > — [sandeepkd on hackernews · 3 comments](https://news.ycombinator.com/item?id=49129394) > (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 > — [marcua on hackernews · 1 comments](https://news.ycombinator.com/item?id=49130673) > 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. > — [ebiester on hackernews · 1 comments](https://news.ycombinator.com/item?id=49128759) > 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 > — [marcua on hackernews](https://news.ycombinator.com/item?id=49130785) > 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. > — [smallerfish on hackernews · 1 comments](https://news.ycombinator.com/item?id=49129798) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49123468) · 57 points · 46 comments ## Community discussion Top comments from developers on daily.dev. **@trevorsuna** · 1 upvotes > Putting the user-controlled database at the center is a useful inversion. PKCE and minimal server state make the simple case attractive; collaboration, revocation, and schema evolution seem like the real tests for how far this model can go. ## Similar posts on daily.dev - [OAuth 2.0 authorization in PostgreSQL using Keycloak as an example](https://daily.dev/posts/oauth-2-0-authorization-in-postgresql-using-keycloak-as-an-example-aoagjltnw) · habr · 9 upvotes · 0 comments --- Tags: [#authorization](https://daily.dev/tags/authorization), [#sqlite](https://daily.dev/tags/sqlite), [#local-first](https://daily.dev/tags/local-first) [View this post on daily.dev](https://daily.dev/posts/authorize-don-t-authenticate-7nbekvqkx)