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.
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.
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.
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.
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.
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.
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
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.
yeah the article is dumb.
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.
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.
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.
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.
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
Nice! If it works with Authelia (or Authentik) too then I'm sold. Thanks for sharing.
Isn't this the core idea behind atproto?
Not sure this does anything for data portability, since apps will just store the data as encrypted & signed BLOBs.