Skip to content

Note

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

FEP-61cf: OpenWebAuthプロトコル仕様書

OpenWebAuthは連合型リモート認証プロトコルである。ActivityPubやZotなどの既存プロトコルと併用可能で、Fediverseやその他の「ソーシャルウェブ」プロジェクト（ブログなど）におけるシングルサインオン機能の実装に活用できる。

概要

OpenWebAuthは、Hubzilla、streams、および関連プロジェクトで採用されている「シングルサインオン」機構である。この仕組みにより、ブラウザベースのユーザーは単一のアイデンティティを用いてFediverse内の各種サービスにログインできる。一度認証が完了すると、サードパーティクッキーを必要とせず、多くの場合明示的なユーザー操作も不要で、他のOpenWebAuth対応サービスからも認識可能となる。

本文書は仕様書、提案書、あるいは「ベストプラクティス」ガイドではない。その目的は、実装者・評価者・動作原理を理解したいすべての関係者に向けて、既存プロトコルの詳細を明確に記述することにある。主に現行実装のリバースエンジニアリングに基づいており、基本的な相互運用性を実現する最小限の要件に焦点を当てている。

OpenWebAuthでは、各ユーザーが公開鍵/秘密鍵ペアによって識別される。本プロトコルが機能するためには、ネットワーク上の他ノードがユーザーの公開鍵を発見できる仕組みが必要である。本稿ではこの目的のためにActivityPubのactorオブジェクトを使用することを前提としている。なお、OpenWebAuthはZot6やNomadなどの他プロトコルとも連携可能であるが、ここではこれらについては言及しない。

概要説明

このプロトコルは以下の2つの参加者間で実施される：

  • 「ホームインスタンス」：ユーザーのアイデンティティを保持するサーバーであり、SAMLおよびOpenID ConnectにおけるIdentity Provider（IdP）に相当する。

  • 「ターゲットインスタンス」：提供されたアイデンティティを用いてリモートユーザーがログインできるサーバーであり、SAMLおよびOpenID ConnectにおけるRelying Party（RP）に相当する。

ログインフローの開始方法

OpenWebAuthによるログインフローは以下の2つの方法で開始可能である：

  • ユーザーがターゲットインスタンスにアクセスすると、ログイン画面が表示される。ユーザーはFediverse IDをフォームフィールドに入力し、「ログイン」ボタンをクリックする。

  • ユーザーがターゲットインスタンスへのリンクをクリックする。このリンクにはクエリパラメータzid=が含まれており、これがユーザーのFediverse IDを指定している。

このzid=方式は必ずしもOpenWebAuth専用ではない。同様の方法で、OAuth2ベースのログインフローを開始することも可能である。ただし実装者は、これにより攻撃が容易になる可能性があることに留意すべきである。悪意のあるリンクをクリックさせた場合、被害者が不正に構築されたアイデンティティを用いてログインフローを開始する可能性があり、MixUpAttackを引き起こす恐れがある。

プロトコルの動作原理

本プロトコルの流れをシーケンス図で簡潔に示す。以下の図はzid=方式を採用したケースを示しており、この場合はユーザーにログインプロンプトが表示されない。

sequenceDiagram
  participant browser as Browser
  participant target as Targetインスタンス
  participant home as Homeインスタンス

  browser ->> target: GET /page?zid=user@home
  target ->> home: webfinger user@home
  home -->> target: リダイレクトエンドポイントのURL情報
  target -->> browser: Location: https://home.example/magic?...
  browser ->> home: GET /magic?...
  Note over home: ユーザー認証状態を確認<br/>（例：セッションクッキーをチェック）
  home ->> target: webfinger /
  target -->> home: トークンエンドポイントのURL情報
  rect rgb(216, 255, 216)
  Note over home,target: アクターの秘密鍵で保護された領域
  home ->> target: GET /token<br/>（署名済み）
  target -->> home: <token><br/>（暗号化済み）
  end
  home -->> browser: Location: https://target.example/page?owt=<token>
  browser ->> target: GET /page?owt=<token>
  target -->> browser: <ページ内容>

フローの開始方法にかかわらず、プロトコルはユーザーのブラウザがターゲットインスタンスにリクエストを送信することから始まる。

1. ホームインスタンスへのリダイレクト処理

まずターゲットインスタンスは、ホームインスタンスの「リダイレクトエンドポイント」を特定する。

既存実装の中にはこのURLを/magicにハードコーディングしているケースもあるが、新規実装では提供されたユーザーIDに対してwebfingerルックアップを実行し、rel属性がhttp://purl.org/openwebauth/v1#redirectに設定されたリンクを検索する必要がある。該当するリンクが見つかった場合、そのhref値がリダイレクトエンドポイントとして使用される。

ターゲットインスタンスはリダイレクトエンドポイントを基に、以下のクエリパラメータを含むURLを構築する： - owa: 必ず1に設定すること - bdest: トークン取得後にブラウザを遷移させる先のURL。この値はUTF-8でエンコードされた後、16進数文字列に変換される。これはOAuth2におけるredirect_uriに相当する。bdest URLにはクエリパラメータを含めることが可能である。

ユーザーのブラウザはこのURLにリダイレクトされる。ターゲットインスタンスは、ウェブフィンガーIDと同じオリジンを持つURLであることを確認する必要がある。これはオープンリダイレクターとして悪用されるのを防ぐためである。

2. ホームインスタンスによるトークン要求処理

ユーザーのホームインスタンスにおける/magicエンドポイントは、まずユーザーのブラウザが有効なセッションクッキーを保持しているかを確認する。

該当する場合、bdest遷移先URLをデコードする。次に、遷移先サイトのルートURLに対してwebfingerルックアップを実行し、rel属性がhttp://purl.org/openwebauth/v1に設定されたリンクを検索する。このリンクが、ターゲットインスタンスの「トークンエンドポイント」を特定する。

この処理段階でエラーが発生した場合、ホームインスタンスは'bdest' URLへのリダイレクトを実施してはならない。これによりオープンリダイレクターとして悪用される可能性がある。その代わりに適切なHTTPエラーコードを返すべきである。

正常に完了した場合、ホームインスタンスは発見したトークンエンドポイントに対して、署名済みのHTTPSリクエストを発行する。このリクエストには、追加の署名付きヘッダーX-Open-Web-Authも含まれる。このヘッダーにはランダムな文字列が格納されており、ターゲットインスタンスはこのヘッダを使用しない。本ヘッダーは、署名計算に追加のエントロピーを付与するために設けられている。

3. ターゲットインスタンスによるトークン提供処理

ターゲットインスタンスのトークンエンドポイントは、keyIdを抽出し、アクターレコードを取得して公開鍵を取り出し、署名を検証する。

正常に検証が完了した場合、URLセーフなランダム文字列を生成し、この値をトークンとして使用する。生成されたトークンはローカルに保存され、メッセージに署名したアクターと関連付けられる。さらに、トークンはアクターの公開鍵を用いてRSA PKCS #1 v1.5暗号化方式で暗号化される。暗号化結果はURLセーフなBase64エンコード形式で表現され（'='パディングバイトは含まない）。

次に、以下のJSONオブジェクトをレスポンスとして構築する：

{
   "success": true,
   "encrypted_token": <base64エンコードされたトークン>
}

参考文献

著作権情報

CC0 1.0 Universal（CC0 1.0）パブリックドメイン献呈

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