はじめに
2026 年 5 月 27 日から 5 月 29 日の三日間に渡ってドイツのライプツィヒで開催された OAuth Security Workshop 2026 (OSW2026) のスポンサーセッションで Shared Signals Framework (SSF) について話してきましたので、その内容を共有させていただこうと思います。
 |
|---|
| OSW2026 に参加した Authlete メンバーの集合写真 |
三つの Shared Signals 最終仕様
2025 年の 9 月、OpenID Foundation (OIDF) は Shared Signals 関連の三つの仕様の最終版が承認されたことを公表しました。それらの仕様とは次の三つです。
| 略称 | 仕様名 | |
|---|---|---|
| 1 | SSF | OpenID Shared Signals Framework Specification 1.0 |
| 2 | CAEP | OpenID Continuous Access Evaluation Profile 1.0 |
| 3 | RISC | OpenID RISC Profile Specification 1.0 |
これらに加え、Internet Engineering Task Force (IETF) の管理下にも下記の関連仕様書群があります。
トランスミッターの動作
Shared Signals Framework (SSF) 仕様はトランスミッター (Transmitter) の動作を定めています。トランスミッターの仕事は、大きく次の二つです。
- Security Event Token (SET) を生成する
- Security Event Token をレシーバー (Receiver) に配送する
Security Event Token (SET) はセキュリティに関する何らかのイベントを表現するトークンであり、その形式は JWT です。詳細な定義は RFC 8417 にあり、また、追加の要件が SSF 仕様内にも存在します (「sub クレームを含んではならない」といった RFC 8417 と衝突する要件もあります)。
Security Event Token のペイロード内で特徴的なクレームは、sub_id と events です。
sub_id
sub_id クレームは当該イベントの主体が何であるかを示しています。ID トークンの sub クレームが単一文字列であるのに比べ、sub_id クレームの値は JSON オブジェクトであり、その構造は思いのほか複雑です。
RFC 9493 には sub_id が取りうる JSON オブジェクトの形式が定義されており、また、SSF 仕様内にも追加の定義があります。
{
"format": "iss_sub",
"iss": "https://issuer.example.com/",
"sub": "145234573"
}
{
"format": "ip-addresses",
"ip-addresses": [
"10.29.37.75",
"2001:0db8:0000:0000:0000:8a2e:0370:7334"
]
}
events
events クレームはイベント種別や関連情報を表しています。値は JSON オブジェクトであり、その JSON オブジェクトはキー・バリューの組を一つだけ含んでいます。そのキーはイベント種別を表す URI です。バリューは JSON オブジェクトであり、任意のイベント関連情報を含む場合があります。関連情報がなければ空の JSON オブジェクトです。
CAEP プロファイル、RISC プロファイル、RFC 9967 は、イベント種別の識別子群とそれらが取りうる関連情報の形式を事前定義しています。SSF 仕様内でも幾つかイベント種別の識別子が定義されています。
"events": {
"https://schemas.openid.net/secevent/caep/event-type/session-revoked": {
"event_timestamp": 1615304991
}
}
"events": {
"https://schemas.openid.net/secevent/risc/event-type/account-disabled": {
"reason": "hijacking"
}
}
"events":{
"urn:ietf:params:scim:event:prov:activate": {}
}
"events": {
"https://schemas.openid.net/secevent/ssf/event-type/verification": {
"state": "VGhpcyBpcyBhbiBleGFtcGxlIHN0YXRlIHZhbHVlLgo="
}
}
トランスミッターの構成
SSF 仕様はトランスミッターが実装すべきエンドポイント群を定義しています。
| エンドポイント | 説明 |
|---|---|
| メタデータ | トランスミッターのメタデータ (設定情報) を公開するエンドポイント。パスは /.well-known/ssf-configuration (ただし正確な定義は仕様を参照のこと)。 |
| ストリーム設定 | ストリームの生成・削除、設定の確認・更新をおこなうためのエンドポイント (※イベントはストリームを介して配信される) |
| ステータス | ストリーム状態の確認・更新をおこなうためのエンドポイント |
| サブジェクト追加 | ストリームにイベント監視対象のサブジェクトを追加します。 |
| サクジェクト削除 | ストリームからイベント監視対象のサブジェクトを削除します。 |
| ストリーム検証 | ストリームの疎通確認をおこなうためのエンドポイント。 |
| ポーリング | イベントをポーリング方式で配信するためのエンドポイント。(詳細は RFC 8936 で定義) |
また、トランスミッターは Security Event Token の署名を検証するのに必要な公開鍵を公開する必要があるため、JWK Set ドキュメント (RFC 7517) を公開するエンドポイントを提供することになります。事実、トランスミッターのメタデータには JWK Set ドキュメントの場所を示す jwks_uri パラメーターが存在します。
SSF 仕様は、これらのエンドポイント群が何らか方法で保護されていることを期待しています。例えば OAuth アクセストークンは保護方法の一例です。
アクセストークン以外の方法で保護する実装もありえます。実際に、あるオープンソース実装では OAuth クライアント認証でエンドポイント群を保護しています。いずれにしても、仕様の要件を満たすためには、明文化されていないものの必然の帰結として、エンドポイント群はアクセスしてきた OAuth クライアントを何らかの方法で特定する必要があります。
加えて、SSF 仕様には書かれていませんが、汎用的なトランスミッターの実装は、任意のイベントをイベントキューに登録する仕組みを提供するでしょう。
SSF の実装は簡単ではない
SSF 関連仕様策定の動機はセキュリティに関するイベントの通知ですが、実際の仕様書を読むと、SSF はかなり汎用的な仕組みであることが分かります。セキュリティ関連イベントだけではなく、任意のイベントを扱うことが可能です。
そのため、仕様が想定しているアイデンティティプロバイダーだけではなく、どのようなイベント発生源もトランスミッターになりえます。
それでは、ということで、様々なイベントソースにトランスミッター機能を追加していこう、という考えに至りますが、残念ながら、SSF トランスミッターを実装するのはそれほど簡単な作業ではありません。というのは、少なくとも下記に挙げる項目を実装しなければならないからです。
- イベントキューの管理
- ポーリングやプッシュでのイベント配信
- エンドポイントの実装
- エンドポイントの保護 (OAuth / MTLS / DPoP / HTTP メッセージ署名 / 他)
- 鍵管理 (Security Event Token 署名用 / HTTP メッセージ署名用 / 他)
SSF の実装をトランスミッターの数だけ繰り返すというのは、とても面倒な作業です。
怠惰なプログラマーの場合
怠惰な※プログラマー (同じ作業を繰り返す面倒を避けたいがために再利用可能な仕組みを構築して後で楽をしようとするプログラマー) は、SSF をどのように実装するでしょうか？
おそらく、トランスミッターのエンドポイント群をサーバーに直接実装することを避け、かわりにトランスミッターの実装を担うバックエンドシステムを一つ作り、それを複数のトランスミッターの実装から利用するという構成にするでしょう。こうすることで、フロントエンドのトランスミッターの実装は軽くなります。
※ 若い方は知らないかもしれませんが、怠惰 (Laziness) はプログラマーの三代美徳の一つとされています。
Larry Wall 著『Programming Perl』より:
And although we don’t intend to teach you how to program, the perceptive reader will pick up some of the art, and a little of the science, of programming. We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris.
そのようなバックエンドシステムは、例えば下記の図が示すように、トランスミッターの Configuration Endpoint に対応する次の API 群を提供するかもしれません。
/stream/delete/stream/read/stream/update/stream/create/stream/replace
Authlete Arena
そのような SSF バックエンドの実例として紹介したいのが、『Authlete Arena』です。これは Authlete 社の新製品です。
レシーバーはトランスミッターにリクエストを投げますが、
そのトランスミッターの実装が Authlete Arena を使っている場合、トランスミッターは受けたリクエストの処理を Authlete Arena に委譲します。Authlete Arena はリクエストを処理し、どのようなレスポンスを返すべきかをトランスミッターに伝えます。この委譲モデルは Authlete の『Semi-Hosted Service パターン』(参考：OAuth 2.0 / OIDC 実装の新アーキテクチャー) と同じです。
ほとんどのケースでは Authlete Arena はトランスミッターの後ろに隠れていますが (Authlete Arena がレシーバーと直接やりとりすることはありませんが)、イベント配信をプッシュ方式でおこなう場合に限り、Authlete Arena はレシーバーのエンドポイントに直接 Security Event Token を配送します。
Authlete Arena の API 群は OAuth アクセストークンで保護されています。
この事実は、Authlete Arena API にアクセスするためのアクセストークンをトランスミッターに発行する認可サーバーが必要であることを示唆しています。
Authlete Arena はアクセストークンの情報を取得するため、またはアクセストークンの署名検証用の公開鍵を取得するため、その認可サーバーにアクセスします。
Authlete Arena の API と同様、トランスミッターのエンドポイントもアクセストークンで保護されます。
この事実は、トランスミッターのエンドポイントにアクセスするためのアクセストークンをレシーバーに発行する認可サーバーが必要であることを示唆しています。
トランスミッターはアクセストークンの情報を取得するため、またはアクセストークンの署名検証用の公開鍵を取得するため、その認可サーバーにアクセスします ー というのが普通の設計ですが、Authlete Arena を使っている場合、アクセストークンのバリデーションを Authlete Arena に委譲することができます。
Authlete Arena は、トランスミッターに代わり、アクセストークンの情報を取得するため、またはアクセストークンの署名検証用の公開鍵を取得するため、その認可サーバーにアクセスします。
Authlete Arena の全ての機能は Web API 経由で制御できます。そのため、CLI だけで制御できます。しかしながら、やはり Web コンソールで制御できると楽なので、Arena Dashboard が提供されます (開発予定)。
Authlete Arena を用いてトランスミッターを実装する際の構成は次の図のようになります。
アクセストークンのバリデーションを Authlete Arena に委譲する利点は、Authlete 社の持つ API 保護に関する専門知識を活用できることです。これらの専門知識には、OAuth、MTLS、DPoP、HTTP メッセージ署名が含まれます。加えて、『Cedar Policy in RAR オブジェクト』といった先進的なアクセス制御機構もサポートされます。
設計の分岐点
おそらく、ほとんどのアイデンティティサーバーの実装は、SSF トランスミッターのエンドポイント群を直接自身に実装するでしょう。実際、あるオープンソースソフトウェアの SSF 実装が予想通りそのようになっていることを最近確認できました。
しかしながら、Authlete 社は熟慮の末、アイデンティティサーバーに依存しない、汎用的な SSF バックエンドシステムを開発することにしました。結果として、既存製品である Authlete から完全に独立した、Authlete Arena という新製品を開発することになりました。
Authlete への機能追加ではなく、独立した製品を開発するという作業は、大きな労力を要しました。しかし、それと引き換えに、SSF を適用できそうなユースケースに全て対応できるようになりました。例えば、最近の事例ですと、「AI エージェント制御の文脈で SSF の利用を検討したい」という相談にも応えられるようになりました。
Arena という名前の由来
セキュリティ関連のイベントに限らず、任意のイベントを扱うことのできる汎用イベント配信メカニズムであることを示すため、スポーツの試合やコンサートといったより広範な意味での「イベント」をおこなう場所である Arena という単語を選びました。元々 Authlete という社名・製品名がアスリート (Athlete) に近いこともあり、Authlete Arena という名称はしっくりくると感じています。
おわりに
10 年前に Authlete 社を起業したときには、まさか自分の会社が業界でもっとも技術的にマニアックなイベントの一つである OAuth Security Workshop のメインスポンサーを務めることになるとは全く想像していませんでした。
ありがたいことに、Authlete 社は利益を出しながら堅実に成長を続けており、日本国内だけではなくグローバル市場でも存在感を高めています。採用も進めていますので、ご興味のある方は是非お問い合わせください。
また、6 月 24 日には『OAuth & OpenID Connect勉強会ー海外イベントから直送! 認証・認可の最新トレンド』と題しまして、OAuth Security Workshop 2026 と Identiverse 2026 の二つの海外イベントの情報共有会をハイブリッドで開催しますので、奮ってご参加ください！
