以前、びるず@bills-appworks.blue さんがアプリパスワードとOAuthの違いについて、以下の記事を書いてくれていました。
OAuthとアプリパスワード @bills-appworks.blue
アプリパスワード（AppPassword）とOAuthの違いについては上記記事を参考にしてください。
この記事では、Blueskyには何故アプリパスワードを使うアプリとOAuthを使うアプリがあるのかについて軽く触れてみます。
Blueskyのサードパーティアプリには2つの認証方法がある
Bluesky関連のサードパーティアプリやクライアントは多数出てきています。 これらのアプリでは大きく2種類の方法でアカウントの認証が行われています。
- AppPassword (アプリパスワード)
- OAuth (オーオース)
何故2つの認証方法があるのか。そしてそれぞれ違っており分かりづらい。という声も見かけました。 たしかに、アプリによってどちらを使うか（あるいは両方使えるケースも）あって分かりづらいの現状です。
歴史的背景
BlueskyのリリースとAppPasswordの登場
Blueskyは当初からサードパーティアプリ向けに認証方法にOAuthを導入することを検討していました。OAuthはアカウントの情報を安全に扱えるので、いまではBluesky以外のWeb全体でも多くの利用された方法です。
しかし、この認証方式を導入するにはどうしても時間がかかります。それだけでなく始まったばかりのBlueskyには他に急いで取りかかるタスクも多くあり、OAuth実装に割く時間がありませんでした。
そこでユーザーの実パスワードを使用せず、暫定的に安全にアプリを利用できるようにするアプリパスワード方式を作り、提供しました。
アプリパスワードは、本パスワードとは別に、アプリ毎に使用する使い捨てパスワードの様なものを発行し、それでアプリからログインできるようにしよう。というものです。
権限の違いなどもありますが、そこは冒頭の記事を参照してください。
これによって、Bluesky初期には多くの開発者が作成したアプリケーションを利用者は安全に利用することができるようになりました。
しかしアプリ毎に異なるパスワードを管理して運用するには、利用者の管理負担が大きくなります。
OAuthの準備と登場
Bluesky本体の様々な実装がある程度進み、OAuth実装に取り組める準備ができました。
Blueskyという分散型サービスで扱うためのOAuth認証の策定と実装が進み、2024年9月頃になり仕様やドキュメントが公開されたのがされるようになりました。
しかし既存の一般的なOAuthとも少し仕様が異なる部分もあり、この時点の最初の頃はまだAppPasswordを採用するアプリも多かったですが、以降しばらくしてからのBlueskyアプリはOAuthを採用したものが徐々に増えてきました。
アップデートとサポート
古くからあるアプリでもアプリパスワードからOAuthに変更したアプリ、あるいは慣れ親しんだアプリパスワード方式を残しつつOAuth方式をサポートしているアプリもあります。
しかし古いままアップデートされていないアプリはアプリパスワード方式しかサポートしていないケースもあります。
今後についてはアプリパスワード方式もBlueskyがサポートを停止してOAuthに転換していくと、AppPassword方式は利用できなくなっていくでしょう。
OAuth利用時にハンドルの入力が必要な理由
OAuthで認証するときに、AppleやGoogle、Microsoftなどのサービスであれば「Signin with 〜」や「○○でサインイン」と書かれたボタンをクリックするだけでログインできます。
画像はサンプル
しかし、Blueskyのアプリではまずハンドルを入力するケースが多いです。
これは何故かというと、Blueskyが分散型SNSであることに起因します。
認証はユーザーのアカウントが存在しているサーバーに対して問い合わせを行います。 しかしBlueskyは（正しくはAT Protocolでは）分散型であるが故に、アカウントがどのサーバー（PDS）にあるかを探す必要があります。 その手がかりとなるのがハンドルです。
まずハンドルからユーザーのサーバーを特定し、そのサーバーに対してOAuthでログインする旨を通信します。ここから初めてOAuth認証の処理が動くことができます。
認証方法ごとの違いについて
アプリパスワード
アプリパスワードはアカウントを使用する際に要求する権限の細かな指定ができません。 アプリパスワードを利用してログインすると、開発者は
- ユーザーのアカウントを通じてBlueskyで利用できるほとんどの機能（設定やセンシティブな情報を除く）を利用できる
- 上記に追加でDMの読み書き権限を追加する（アプリパスワードの画面で選択可能です）
例えば、ログインしてプロフィールを使用するだけのアプリケーションでもあなたのタイムラインを読み書きしたり、他のアカウントをフォローできる権限を有している状態です。
さらに、なるべくアプリ毎に発行されたパスワードを使用し、管理する必要性が出てきます。
OAuth
開発者は接続するアプリに必要な権限だけを要求することができます。 現在のところはアプリパスワードとほとんど同じ権限を要求して利用しているアプリも多いですが、明確に指定しているアプリもあります。
利用者はOAuthでログイン時に表示される確認画面で、各アプリがどのような権限を要求しているか確認することができます。
自分が利用しようとするアプリが過剰に権限を要求していないか（目的に沿っているか）を事前に確認することができます。
イベントの参加可否を表明、確認できる SomekeSignalのOAuth画面の例。ユーザーは確認画面の?をクリックして求められる権限の詳細を、事前に確認することができます。
結局どっちが良いの
段階的な導入なので良い悪いはないですが、どちらかと言えばOAuthの方が良いです。
開発者視点としては、必要最小限の情報と権限だけ要求し、余計な事ができない方が明確で良いです。もし万が一アプリに脆弱性があって、自分のアプリ経由で意図せずおそろしい操作（例えば、すべての投稿が消せてしまう、パスワードをリセットできてしまうなど）ができてしまった場合、責任が取れません。
利用者視点でも、これから利用しようとするアプリがどのような権限を要求していて、どのような走査を仕様としているのかを、事前により細かく明確に権限を確認できて良いです。 また、既にログイン済みアカウントの場合はパスワード入力を省略できるます。
上記理由により、総合的にはOAuthの方が良いです。
OAuthは今後充分な移行期間を経て移行していき、最終的にはApp Passwordは非推奨とされる流れになるようです。
そのため、将来的にはOAuthのみに統合されていきます。
まとめ！
BlueskyはまだSNSとして、そしてその土台作りと併せて始まったばかりの新しいプラットフォームです。 そのため、今までにはない仕組みがあったり魅力的な部分もありつつ、変化の激しいプラットフォームでもあります。しばらく使っていないうちに新しい機能、新しい仕組みがドンドン取り込まれていきます。
しばらくぶりだと変化の範囲が大きくてビックリしますが、毎日使っていればその差も僅かです。 毎日使って慣れていくのもいかがですか？
最近また少しずつアクティブな利用者も増えつつあります。この機会にたくさん使っていきましょう！
