自前の認証基盤を、仕様どおりに保つには
認証は IDaaS に任せるのが基本、という考え方は今も正しいと思います。それでも自社で認証基盤を持つ企業はあります。金融や決済で FAPI 2.0 のような厳しいプロファイルへの準拠を求められる場合、グループ各社のサービスを一つのIDでまとめたい場合、利用者数が多く外部サービスの費用が見合わない場合などです。
仕様どおりに見えて、違っている
OpenID Connect や OAuth 2.0 の実装は、ログインが一通り動いた時点で完成したように見えます。ところが、問題が出やすいのはその先です。
- リダイレクト先のURLを、登録された値と完全一致で比べているか
stateやnonce、PKCE の検証を省いていないか- 署名アルゴリズムに
noneを指定したリクエストを拒否しているか - アクセストークンやリフレッシュトークンの寿命と、失効の扱いが決まっているか
- ログアウトしたとき、連携している各サービスのセッションも終わるか
どれも普段の利用では目に見えず、攻撃されたときに初めて差が出ます。2026年10月に公表されたIDCFクラウドへの攻撃では、クラウドポータルの認証システムに使われていたオープンソースソフトウェアの脆弱性が侵入の入口になりました。認証まわりは、自分で書いたコードだけでなく、依存しているライブラリまで含めて追い続ける必要があります。
OFCS で確かめる
OpenID Foundation は、仕様への適合を確かめるためのテストスイート「Conformance Suite」（OFCS）を公開しています。OpenID Connect Core や FAPI 2.0 などのテストプランを、自分たちの認可サーバに対して実行できます。OpenID Foundation の認定（OpenID Certification）も、このスイートでの実行結果をもとに申請する仕組みです。
実際に回してみると、いくつか分かることがあります。
まず、自動で合否が決まるテストばかりではありません。エラー画面が正しく表示されたかなど、画面を見て人が判断する項目もあります。また、設計として意図的に拒否している機能のテストは、失敗ではなく対象外として扱うべきものです。結果を読むには、テストの意図と自分たちの設計判断の両方を知っている必要があります。
次に、一度通っても、ライブラリの更新や設定の変更で簡単に崩れます。OFCS はコンテナで手元に立てられるので、継続的インテグレーションに組み込み、リリースの前に回帰テストとして実行するのが現実的です。
認定を取るかどうか
OpenID Certification の取得は、取引先や監督官庁に対して適合を示す手段になります。費用と手間がかかるので、すべての基盤に必要なわけではありません。認定を取らない場合でも、OFCS を回帰テストとして使い、結果を記録しておく価値は十分にあります。
あまつかぜがお手伝いできること
OpenID Provider を実装してきた経験をもとに、認証基盤の設計レビュー、OFCS を実行できる環境づくり、失敗したテストの原因調査と修正、認定申請の準備までを支援します。
関連するサービス
参考
- OpenID Foundation「OpenID Certification」
- OpenID Foundation「Conformance Suite」