「認証」するな、「認可」せよ：セキュアな設計の鉄則

システム設計において、認証（Authentication）と認可（Authorization）を混同してはいけません。認証は「誰であるか」を確認するプロセスですが、システムのセキュリティを担保するのは、そのユーザーに「何ができるか」を制御する認可の仕組みです。認証の成功を認可の完了と誤解するアンチパターンを避け、API設計や権限管理においては、常に認可レイヤーを第一に考えましょう。

結局「ファイル」→「開く」に戻ったってことか。ついでにWebアプリじゃなくてネイティブアプリを使ってもいいはずなんだけどね。

残念ながら、このアプローチは多くの（Web）アプリでは通用しないんだ。

これでデータのポータビリティが確保できるかは微妙だな。結局アプリ側はデータを暗号化して署名済みのBLOBとして保存しちゃうだろうし。

1. パフォーマンスの問題はどう回避するの？こっちの結合処理が重いのにDBが遅かったり、接続が不安定だったりした場合、自分の側でどうやってデバッグすればいいんだ？

2. セキュリティが甘いとして、俺（あるいは攻撃者）が悪用するのを何が止めるんだ？100％安全だって断言できるのか？

3. コラボレーションについて触れてるけど、会社単位で複数のユーザーがいてアクセス権を管理しなきゃいけない場合、どうなるんだ？この場合、データに対する権利を持ってるのは会社本体だぞ。

認証と認可をまとめて扱ってるツールやライブラリが多すぎるんだよね。アイデンティティ管理を外部委託できる認可サーバーを見つけるのは至難の業だよ。

（よく「auth」っていう曖昧な略称で両方まとめて語られがちだけどね。）

宣伝になっちゃうけど、同僚と一緒に最小限の認可サーバーを作ってみたよ。好きなアイデンティティプロバイダー（Entra IDやAuth0/Oktaとか）を使って認可を制御できるんだ。識別されたユーザーが持つべき役割や権限を調べて、その認可情報を含んだトークンを発行する仕組みだよ。

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

興味深いトピックだけど、「認証」と「認可」という言葉の使い方が不適切じゃないかな。本質的なトピックは「データオーナーシップ」だと思う。

表面的なレベルで言えば、ユーザーがデータを所有するというコンセプトは納得できるし、実際そうしたサポートは各プロバイダーやアプリ間でバラバラに存在しているしね。

ただ、ユーザーがデータベースを持って、それを各サービスに認可するっていう具体的なアイディアは、現実的にはかなり無理がある。管理された環境下での実験ならいいかもしれないけど、それ以上の規模にはスケールしないよ。

1. データベースにはメンテナンス、バックアップ、フェイルオーバーが必要。

2. スキーマの更新は悪夢。特に規模が大きくなればなるほど、誰もやりたがらないはず。

3. ここで言っている認可の仕組みは「1対多（1つのDBに対し複数のアプリ）」のように見えるけど、更新処理を考えるとこれじゃ破綻する。

それってatprotoのコアコンセプトと同じじゃない？

自分用のタスクマネージャーを数年前からちょこちょこ自作してるんだ（https://the.do.zone ）。DBは使ってなくて、メインの保存先はブラウザ。必要に応じてローカルファイルシステム（Chromeの場合）やDropbox、Googleドライブ（トークン長の制約が厳しくて微妙だけど）に同期できるようにしてる。泥臭いけど一応動作する差分解決機能も実装したから、複数マシン間での同期も可能だよ。ブラウザがもっとこういうアプリ構成を簡単に書けるツールを提供してくれたらいいんだけどね。理論上はクラウドプロバイダーがデータストアの標準規格を提供してくれたら理想的だけど、そんな市場は存在しない。一般のユーザーは、自分のデータがどこにあるかなんて実際ほとんど気にしてないからね。