Skip to content

Note

このドキュメントは2026-02-27 02:36PLaMo Translation Modelを使用して自動翻訳されました。

FEP-d8c2: OAuth 2.0プロファイル for ActivityPub API

概要

本FEPでは、ActivityPubオブジェクトIDをOAuth 2.0認証コードフローにおけるclient_idとして利用するための仕組みを定義します。

(以前のバージョンでは完全なOAuth 2.0プロファイルとしてActivityPub APIとの連携方法を規定していましたが、今回の改訂版ではクライアントID機構に特化して簡潔化しました。タイトルはFEPツールとの互換性維持のためそのまま残しています。)

背景

ActivityPubでは、ストリーム指向ソーシャルソフトウェア向けのRESTful HTTP APIであるActivityPub APIが定義されています。このAPIにより、クライアントアプリケーションはアクター、コレクション、アクティビティ、およびコンテンツオブジェクトといったActivityPubオブジェクトを読み取ることが可能です。また、クライアントアプリケーションはアクターのoutboxコレクション(「client-to-server」または「c2s」とも呼ばれます)に投稿することで、新たなActivityオブジェクトを作成することもできます。

ActivityPub仕様書ではAPI向けの認証機構を定義していませんが、ActivityPub Primer Authorization and Authenticationガイドラインではいくつか提案がなされています。APIクライアントに対する認証方式には様々な実装方法が考えられますが、OAuth 2.0は広く普及しており理解が進んでいるフレームワークです。

OAuth 2.0は非常に広範な概念であり、多様な技術やユースケースを網羅しています。OAuth 2.0 Simplifiedでは、OAuth 2.0の最も一般的なプロファイルである[認証コードフロー](https://datatracker.ietf.org/doc/html/rfc6749#section-4.1)とベアラートークンについて詳述されています。多くのOAuth 2.0クライアントライブラリはこのプロファイルを実装しています。

OAuth 2.0認証コードフローを実施するには、クライアントがフローを開始するために主に2つのエンドポイントが必要です:認可エンドポイントとトークンエンドポイント。これらは、ActivityPubアクターのendpointsプロパティまたはRFC 8414で規定されている[Authorization Server Metadata](https://datatracker.ietf.org/doc/html/rfc8414)エンドポイントから取得可能です。

OAuth 2.0フローでは、クライアント識別子を使用して、ユーザーに対してクライアントソフトウェアに関する重要な情報を提供するとともに、特定の種類のなりすまし攻撃を回避します。

OAuth 2.0の一般的なユースケースとして、単一プロバイダーが提供するAPIが挙げられます。単一プロバイダーの場合、クライアント開発者はプロバイダーの開発者向けWebサイトやその他のツールを用いてオフラインでクライアントIDを登録できます。

Fediverseのように複数のプロバイダーが存在する場合、このようなオフライン登録方式は現実的ではありません。インターネット上には数万ものActivityPubサーバーが存在しており、各プロバイダーごとに手動でクライアントIDを登録することは不可能です。

一つの解決策として、RFC 7591で規定されている[Dynamic Client Registration]プロトコルを利用する方法があります。この規格では、認証サーバーにアプリケーションを登録し、一意のクライアント識別子を取得するための標準的なHTTPエンドポイントが定義されています。

動的クライアント登録はクライアント側に追加的な複雑さをもたらします。特に、クライアントソフトウェアは、使用する各認可サーバーに対して正しいクライアントIDを保持し続ける必要があります。

本プロファイルでは、これらの課題に対処するため、単一の明確に定義されたActivityPubオブジェクトを用いてクライアントソフトウェアを特定・記述する仕組みを提供します。

クライアント識別子

ActivityPubでは、ソーシャル空間内のオブジェクトを記述するための豊富な語彙が提供されています。ActivityPub世界における各オブジェクトは固有のhttps: URIを持ち、このURIは必ずJSON-LDドキュメントを参照できるものでなければなりません。

これにより、オフライン登録を必要としない分散型のActivityPub APIクライアント説明が可能になります。

id属性から参照されるオブジェクトは、[Application]または[Service]タイプである必要があります。また、client_idパラメータと同じ値を持つidプロパティを必ず含む必要があります。さらに、クライアントのリダイレクトURIを示すredirectURIプロパティも必須です(詳細は後述の[Context文書]を参照)。

クライアントは以下のメタデータを提供することで、ユーザーが認証判断を行いやすくなるよう支援する必要があります:

  • nameMapまたはname: クライアントソフトウェアの名称
  • icon: クライアントソフトウェアのアイコンを表すImageオブジェクト
  • summaryMapまたはsummary: アプリケーションやサービスの説明
  • attributedTo: クライアントソフトウェアを担当するアクターのnameidicon、およびsummaryプロパティ

発見可能性

ActivityPubオブジェクトIDをOAuth 2.0クライアントIDとして利用するためのサポートは、以下の2つの方法で宣言可能です。

アクターによる発見

ActivityPubアクターはobjectIDAsClientIDプロパティを含めることができます。この値がtrueの場合、クライアントソフトウェアはこの仕様書で規定された形式を用いて自身を認可サーバーに識別させることができます。

Authorization Server Metadata

認証サーバーは、その[Authorization Server Metadata](https://datatracker.ietf.org/doc/html/rfc8414)にactivitypub_object_id_as_client_idフラグを追加することで、ActivityPubオブジェクトIDをクライアントIDとして利用することを宣言できます。

Context文書

本仕様書のContext文書はhttps://purl.archive.org/socialweb/oauth/2.0に配置されています。その内容は以下の通りです:

{
  "@context": {
    "oauth": "https://purl.archive.org/socialweb/oauth#",
    "redirectURI": {
      "@id": "oauth:redirectURI",
      "@type": "string"
    },
    "activitypub_object_id_as_client_id": {
      "@id": "activitypub:objectIDasClientId",
      "@type": "boolean"
    }
  }
}

セキュリティ考慮事項

  • OAuth 2.0 Security Best Current Practiceでは、OAuth 2.0を実装する際のベストプラクティスが多数紹介されています。
  • OAuth 2.0を実装する際に伴うリスクの一つとして、認証完了後にユーザーがredirect_uriパラメータへリダイレクトされる点が挙げられます。この仕組みは攻撃者によって悪用され、認可サーバーをオープンリダイレクターとして利用される可能性があります。OAuth 2.0の認可エンドポイントをオープンリダイレクターとして利用したアプリケーションは、各リクエストごとに異なるredirectURIを持つようにクライアント説明文書を変更することで不正な操作を行う恐れがあります。対策として、各クライアントのredirectURI値をアーカイブしておき、値が頻繁に変更された場合にはフローを中止する方法が考えられます。
  • クライアント提供のURIを取得する必要のあるプロトコル全般に言えることですが、サーバー側はclient_idパラメータを参照する際に細心の注意を払う必要があります。これにより、非常に大きなレスポンスや生成に時間がかかる応答、あるいはフォーマットが不十分なコンテンツといった攻撃を回避できます。
  • ActivityPubオブジェクトとして定義されるクライアントには、nameiconのように偽装可能なメタデータが含まれています。攻撃者は人気アプリケーションの名称、アイコン、または発行元情報を利用してユーザーを騙し、自身のアプリケーションへの認証を行わせる可能性があります。共有ブロックリストや評判システム、ユーザー教育などのツールを活用することで、このリスクを軽減できます。

IANAに関する考慮事項

OAuth Authorization Server Metadataレジストリ

以下の認可サーバーメタデータ値は本仕様書で定義され、OAuth 2.0 Authorization Server Metadata RFC8414においてIANAに登録されています。

  • メタデータ名称: activitypub_object_id_as_client_id
  • メタデータ説明: 認証サーバーがActivityPubオブジェクトIDをクライアントIDとして利用することを許可しているかどうかを示すブール値
  • 変更管理責任者: W3C Social Web Incubator Community Group
  • 仕様文書: https://fediverse.codeberg.page/fep/fep/d8c2/

参考文献

著作権

CC0 1.0 Universal(CC0 1.0)パブリックドメイン献呈

法律で許容される範囲内において、本Fediverse Enhancement Proposalの著者らは当該著作物に関するすべての著作権および関連権利を放棄しています。