Web開発
認証ではなく、認可を
Authorize, don't authenticate (blog.marcua.net)
要約
この記事は、従来のWebアプリケーションにおける「認証」中心のアプローチに疑問を呈し、「認可」を重視する新しいモデルを提案しています。ユーザーは自分のデータへのアクセス権をアプリケーションに証明するのではなく、アプリケーションに自分のデータベースへのアクセスを許可(認可)すべきだと主張しています。これにより、ユーザーは自身のデータに対する真の主導権を取り戻すことができます。
全文翻訳
あらゆるWebアプリケーションのログイン画面は、そのアプリケーションがあなたに「私のデータベースにあるあなたのデータにアクセスするために、あなたが誰であるかを証明してください」と言っているのと同じです。あなたは、自分のデータを提供する特権を得るために、アプリケーションで認証を行っています。
以前のブログ記事で、アプリケーションがあなたのデータを制御することの欠点について説明しました。アプリケーションの所有者は、あなた自身のデータへのアクセスを制限できます。データを削除できます。第三者にデータを販売できます。他の人がデータにアクセスできるようなバグを導入するかもしれません。あるいは、侵害されるかもしれません。あるいは、単に後でポリシーを変更したり、所有権や経営陣の変更を見たりするために、これらすべてを回避することもできます。
一言で言えば、ナンセンスです。それはあなたのデータです!あなたは、それにアクセスする権利があることを誰にも証明する必要はありません。誰もあなたが自分のデータをどのように使うかを指示すべきではありません。そして、誰もあなたが快適でない方法であなたのデータを使用すべきではありません。
あなたのデータに対する主体性を得るためには、それが存在するデータベースに対する主体性が必要です¹。あなたがデータベースを所有していれば、実際にデータを所有しています。しかし、データベースを実行することは、平均的なインターネットユーザーに期待できるような簡単なことではありません。そして、個人用データベースを実行したとしても、アプリケーションはどのようにそれにインタラクトすべきでしょうか?
過去数ヶ月間、私は個人のデータベース認可の概念を探求してきました。これは、あなたが制御するデータベースへのアプリケーションのアクセスを許可できるようにするものです。具体的には、データベースを簡単に作成し、共同作業者と共有し、どこからでもクエリできるようにするための私のプロジェクトであるaybに、認可フローを組み込みました。
あなたが所有するデータベースへのアプリケーションのアクセスを許可する方法を示すビデオがあります。重要なのは、アプリケーションにはログイン画面がなく、代わりにあなたのデータが存在するデータベースを要求することです。
認可の実行:ログイン画面がなく、あなたが制御するデータベースへのアクセスを要求するToDoアプリケーション。
Todosは私が作成し、日常的に使用しているToDoリストアプリケーションです。
あなたのデータを保持する
ビデオで見られることの背後にある3つの原則を以下に示します。
認証ではなく、認可。
従来のWebアプリケーションでは、ログイン/本人確認のためにアプリケーションで認証します。パスワード/パスキー/...で本人確認を行った後、データにアクセスできるようになります。これにより、アプリケーションがあなたのデータを管理することになります。代わりに、あなたはアプリケーションにあなたの個人用データベースへのアクセスを認可すべきです。ビデオでは、Todosが「本人確認をしてください!」(パスワードを入力してください!)ではなく、「データベースを接続してください」(私を認可してください!)と尋ねているのがわかります。
このフローをサポートする技術は十分に理解されており、広く使用されています。Todosは、データベースをクエリするためのトークンをaybに要求するためにOAuth2フローを開始します。私は、アプリケーションに代わってこれらのOAuth2インタラクションを管理するayb.jsライブラリをオープンソース化しました。エンジニアは1時間以内に新しいアプリケーションにそれを統合できます。
データベースの作成は、ドキュメントの作成と同じくらい簡単であるべきです。
ほとんどのユーザーは、Microsoft WordやGoogle Driveを開いて空のドキュメントを作成できます。一方で、ほとんどのユーザーは、定期的にバックアップされ、実行中のアプリケーションに接続できるPostgresデータベースをセットアップする方法を知りません。ビデオでは、認可フローにより、既存のデータベースを選択するか、新しいデータベースを作成できます。新しいデータベースの作成は、名前を付けるのと同じくらい簡単です。データベースを作成すると、設定なしで定期的なスナップショット/バックアップを受け取ります。アプリケーションはaybと通信し、マイグレーションを実行し、そこにデータを保存する方法を知っています。
データベース作成フローは、今日のほとんどのデータベースよりもはるかに簡単な、コンピューターやクラウド上のファイルを作成するフローと同じくらい難しくありません。
アプリケーションは、ユーザーのデータベースの外にできるだけ少なく格納すべきです。
ビデオのTodosアプリケーションは、静的なHTML、CSS、JavaScriptです。訪問者については何も知りません。サーバーログのどこかに、リソースをダウンロードした人のIPアドレスを見つけることができると想定していますが、それ以外は、アプリケーションは私のサーバーに状態を保存しません。プライバシーを強化するために、自己完結型のindex.htmlファイルをダウンロードしてアプリケーションを自己ホストすることもできます。
Todosを最初にロードすると、開始するためにデータベースに接続するように求められます。データベースをクエリするためのトークンを取得すると²、あなたのすべての個人的なToDoリストアイテムは、あなたが所有するそのデータベースに保存されます。いつでもTodosへのアクセスを取り消すことができます。
ホストを信頼する
あなたが制御するデータベースにデータを保存することの利点を祝ったばかりですが、少し風船を萎ませなければなりません。これまでのところ、私は効果的に「データを他人に保存しないで、aybと呼ばれるものに保存してください」と言ってきました。
aybはオープンソースであり、自分でホストすることもできますが、あなたはそうしたいですか?aybはインストールと実行が非常に簡単だと信じていますが、すべてのユーザーがデータベース管理者になるべきだとは全く思っていません。
これにより、ユーザーは悩ましい選択に直面します。サードパーティのアプリケーションへの信頼を、サードパーティのデータベースホストへの信頼と交換することです。私たちは単に一形態の集中化を別の形態と交換しているだけなのでしょうか?
アプリケーションを操作するデータベースから分離することには、まだ利点があると思います。まず、実際に選択肢が得られます。すべてのアプリ開発者があなたのデータの断片の管理者であることを暗黙のうちに受け入れるのではなく、使用するアプリケーションの数に関係なく、一度だけデータの保存場所を選択できます。
この抽象化は、aybのようなツールに慣れれば、複数のアプリケーションに使用できることを意味し、うまくいけば、あなたのデータに対する主体性を取り戻すコストを償却できます。aybはオープンソースなので、データの保存場所を選択できます。
私は、協同組合や組織がユーザーにデータに対する主体性を提供したい場合に、自己ホスティングの代替手段を提供し、あなたのデータの管理者になるために競争できる日が来ることを夢見ています。
最後に、aybはファイル形式を発明しません。あなたのデータは、SQLiteやDuckDB³のような、退屈で広く受け入れられているファイル形式で保存されます。まもなく、データを持ち出して別のホストに移行しやすくするために、エクスポートおよびインポートエンドポイントを追加する予定です。
個人データを超えて:共同作業とソーシャルインタラクション
「認証ではなく、認可」モデルは、データが明確に「所有」されている状況で最もスムーズに機能します。データセットが共同作業やソーシャルインタラクションの結果であるほど、誰がデータを所有しているかが不明確になり、アクセスを認可するのが難しくなります。
共同作業は、「個人データ」の定義が曖昧になる場所の1つです。自分でドキュメントを編集している場合、アプリケーションに「私のドキュメント」を「私のデータベース」に保存するように指示するのは簡単です。しかし、Googleドキュメントのような共同編集ツールを使用していて、他の人とドキュメントを編集している場合、「個人用データベース」にそのドキュメントを保存するとはどういう意味でしょうか?
aybはデータベースを共同作業者と共有できますが、各データベースには所有者がいます。ユーザーが共同作業しているデータのために両方のデータベースを同期させ続けるためにアプリケーションを認可する、共同作業型個人データベースのモデルを探求するのは興味深いでしょうが、それは私が構築、プロトタイプ、または理解している範囲を超えています。
ソーシャルデータは、共同作業に基づいたもう1つの種類のデータです。私たちは、大規模な組織が私たちのソーシャルメディアデータを保存し、そのデータをどのように表示するかを制御するアルゴリズムとインターフェースを所有することの欠点を見てきました。ActivityPub/MastodonやAT Protocol/Blueskyのようなプロジェクトは、ユーザーにソーシャルデータの保存場所について、さまざまな方法(ActivityPubのフェデレーション対AT Protocolのストレージと集約の分離)で、より多くの選択肢を提供しています。
それでも、落とし穴があります。これらのプロジェクトはデータの保存場所の選択肢を提供しますが、保存されたデータは、他のすべての人のタイムラインに集約されない限り、有用ではありません。タイムライン集約のソリューションは、ほとんどの人がインフラストラクチャと運用上のコン(...