Authorize, Don't Authenticate: Reclaiming Control Over Your Personal Data
I argue that users should authorize applications to access their own databases rather than authenticating with centralized services. By building tools like ayb and Todos, I demonstrate how creating a personal database can be as simple as creating a document. This approach shifts data ownership back to the user, allowing them to revoke access anytime while avoiding the risks of third-party data custodians.
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.'
- jdub
(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.
:-)
- sandeepkd
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
- pakl
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.
- zkmon
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.
- _def
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.