認証デバイスを Web Push（PWA）で代替できるようにする（ネイティブ開発環境を不要にする）

[OsscJpDevInfra]

概要

CIBA の承認端末を、Web ブラウザ（PWA）の Web Push で代替できるようにしたい。
現在の認証デバイス（authentication_device、Flutter）は、実機で確かめるのに
Android / iOS のビルド環境と署名・配布の手当てが要る。確認したいのは CIBA の承認フローだけで、
そのためにネイティブの開発環境を用意するのは重い。

現状

下地は既にある。 測った結果は次のとおり。

箇所	状態
lib/configs/app_fcm.dart:19	vapidKey = '<YOUR_PUBLIC_VAPID_KEY_HERE>'（プレースホルダ）
lib/components/appauth_page.dart:93	getToken(vapidKey: AppFcm.vapidKey) ＝ Web Push 用の呼び出し形（VAPID は Android / iOS では無視される）
web/	index.html / manifest.json / アイコン 192・512 が存在（Flutter の web ターゲット）
README.md	web / VAPID への言及は無い

サーバ側は無改造で済む見込み。 CommonLibrary/Notifications/FcmService.cs:103-125 は
Notification + Data + Token だけを設定し、Webpush / Android / Apns はコメントのまま。
FCM は Web の登録トークンも同じ Token で配信するため、
/SetDeviceToken（device_token）と /ciba_result（auth_req_id）の口も現状のまま使える。

E2E テスト側は、既にプッシュを送信箱（FcmOutboxDirectory）のファイルで代替している（#196）。
本件はテストの代替ではなく、人が実機相当で触る手段を増やすもの。

対応

1. firebase_messaging の web 初期化と Service Worker（web/firebase-messaging-sw.js）を追加する
2. VAPID 公開鍵を設定で渡せるようにする（現在はソース内のプレースホルダ）
3. web/manifest.json を PWA として成立する内容にする
4. HTTPS で配信する手順を README.md に書く（Web Push は localhost 以外で HTTPS が必須）
5. 既存の Android / iOS 経路は壊さない（同じ lib/ を共有し、web を足すだけ）

制約を明記しておく。

• iOS の Web Push は、PWA をホーム画面に追加した場合のみ（Safari 16.4 以降）。
  「ネイティブ不要」が全プラットフォームで成り立つわけではない
• /ciba_result は、承認が当該ユーザ宛ての要求かの確認が入っていない。
  承認端末を増やす前に、そちらの手当てが別途必要（別途報告済み）

検証

• flutter build web が通ること
• ブラウザで登録トークンが取れ、/SetDeviceToken に登録できること
• CIBA 要求でプッシュが届き、Allow / Deny が /ciba_result に届いて、
  クライアントがトークンを取得（または access_denied）できること
• 既存の E2E（EX-8 / RT-196）が通ること。送信箱による代替は変えない

利用者への影響

無し。 認証デバイスはサンプル / テスト用で、製品の動作は変わらない。
サーバ側に変更が入らない見込みのため、既存のネイティブ アプリもそのまま動く。

[OsscJpDevInfra]

着手前に、本文の前提を実測で確かめた。2 つの前提が成り立たなかったため、対応を見直す。

測定環境: Flutter 3.41.9（stable）/ Dart 3.11.5 / Windows 11（Android SDK 無し）。
git の管理下にあるファイルだけを別のディレクトリに書き出して測った。

1. 現行の Flutter でビルドできない → #209 に分離

flutter build web がコンパイル エラー 10 件で失敗する（アプリ側 1 件、依存側 9 件）。
依存が 2021 年頃の版で固定されているためで、プラットフォームとは関係ない。

本件は #209（依存の更新）の完了を前提とする。 詳細はそちらに書いた。

2. サインインを web 向けに自前で実装する

lib/components/appauth_page.dart は flutter_appauth で認可コード ＋ PKCE → トークン取得を行い、
その access token で /SetDeviceToken を呼んでいる。

パッケージ	今の版	最新版	web
flutter_appauth	1.0.0（android, ios）	12.1.0（android, ios, macos）	最新でも非対応
flutter_local_notifications	6.0.0（android, ios, macos）	22.3.0（…, web）	最新なら対応
firebase_messaging	10.0.1	16.6.0	対応

本文の「同じ lib/ を共有し、web を足すだけ」は成り立たない。

CIBA 用のライブラリは要らない。
CIBA の仕様は、OP と認証デバイスの間のやり取りを範囲外としている。
認証デバイスはプッシュを受けて /ciba_result（MPAS 独自）へ POST するだけで、
flutter_appauth を使っているのは認証デバイス自身のサインイン（通常の OAuth 2.0）である。

サインインは、ライブラリを使わず自前で実装する。
FrontendTemplates の flutter_template/lib/touryo が参考になる
（テスト用なので、テンプレートに準拠する必要はない）。

• 流用できる: 認可コード ＋ PKCE（S256）＋ state の生成、/token での交換（http だけで、client secret 無し）
• 書き足す必要がある: web で認可レスポンスを受け取る処理。
  テンプレートは外部ブラウザを開いて戻りを受ける作りで、web 向けの分岐（kIsWeb）は無い
  （フラグメントを Uri.base から読む旨がコメントで示されているだけ）

3. サーバ側

CORS のためのサーバ改造は、不要の見込み。

• net10.0 : Startup.cs:147-151 で全体に UseCors(AllowAnyOrigin / AnyMethod / AnyHeader)
• net48 : OAuth2EndpointController.cs:105 に [EnableCors(origins: "*")]
• /SetDeviceToken を持つ OAuth2EndpointController に [Authorize] は無い（Bearer はアクション内で検証）

ただし net10.0 は UseCors が UseAuthorization の後ろにある（公式に推奨される順序と逆）。
ブラウザからの呼び出し（プリフライトを含む）は実測していない。

HTTPS は、アプリ側の修正が要る。
lib/configs/app_auth.dart:21-23 の /SetDeviceToken / /ciba_result は http:// で組み立てている
（authentication_device/ANALYSIS.md 8 節 4）。
HTTPS で配信する PWA からは mixed content としてブロックされる。

Firebase の web 用の構成も要る。
web では Firebase.initializeApp に構成を渡す必要があり、今は無い
（Android 用の google-services.json もプレースホルダ。同 5 節）。

4. 本文の古い記述

制約の 2 点目「/ciba_result は、承認が当該ユーザ宛ての要求かの確認が入っていない」は、
修正済み（6f6eda1）。返答の及ぶ範囲は E2E の EX-8.3 で確かめている。

5. 対応の見直し（案）

0. 前提: 認証デバイス（authentication_device）を現行の Flutter でビルドできるようにする（依存の更新） #209 の完了
1. firebase_messaging の web 初期化と Service Worker（web/firebase-messaging-sw.js）を追加する
2. VAPID 公開鍵と、Firebase の web 構成を、設定で渡せるようにする
3. web/manifest.json を PWA として成立する内容にする
4. サインインを自前で実装する（認可コード ＋ PKCE。flutter_template/lib/touryo を参考にする）
5. エンドポイントを https:// にし、HTTPS で配信する手順を README.md に書く
6. 既存の Android / iOS 経路は壊さない。Android SDK の無い環境で作業した場合は、その確認は「未検証」と明記する

4 は、Android / iOS も同じ自前実装に寄せる（flutter_appauth を外す）か、web だけ分けるかを、実装時に決める。

検証に次を加える。

• ブラウザから /token・/SetDeviceToken・/ciba_result を呼べること（プリフライトを含む。net48 / net10.0 の両方）

[OsscJpDevInfra]

対応の状況をまとめる。

コミット: d560c1d / de92324 / 24ec00d / 37ae903

対応

#	対応	状態
1	firebase_messaging の web 初期化と Service Worker	✅ web/firebase-messaging-sw.js を追加。JS SDK は 12.17.0（firebase_core_web が読み込む版に合わせた）。構成は、登録する URL のクエリで渡す
2	VAPID 公開鍵を設定で渡せるようにする	✅ firebase_web.json（gitignore）を --dart-define-from-file で渡す（app_firebase_web.dart）
3	web/manifest.json を PWA として成立する内容にする	✅ 説明文を直し、インストールできることを実機で確認
4	HTTPS で配信する手順を README.md に書く	✅ ただし条件を書くところまで。スマートフォン向けの配信環境は #211 に分離
5	既存の Android / iOS 経路を壊さない	⚠️ 未検証。 Android SDK が無い環境のため（#209 から継続）。接続先の既定値が localhost になったので、実機では接続先のファイルを渡す必要がある

サーバ側の変更は、クライアントの登録 1 件だけ（AuthenticationDevice_Web。パブリック クライアント、redirect_uri は http://localhost:5610/）。CommonLibrary やコントローラのコードは変えていない。

サインインは自前で実装した（web_sign_in.dart。認可コード ＋ PKCE ＋ state）。flutter_appauth は最新版でも web に対応していないため。参考にしたのは FrontendTemplates の flutter_template/lib/touryo。

バックグラウンドの通知から応答できるようにした（web/firebase-messaging-sw.js ＋ web_push_click.dart）。SDK は、開く先の指定が無い通知ではクリック時に何もしないので、自前の notificationclick を SDK の初期化より前に登録し、通知の中身を URL のクエリでアプリに渡している。

検証

検証	結果
flutter build web が通ること	✅ flutter analyze は error 0 / warning 7 / info 6（warning は #209 以前からのもので、増えていない）
ブラウザで登録トークンが取れ、/SetDeviceToken に登録できること	✅
CIBA 要求でプッシュが届き、Allow / Deny が /ciba_result に届いて、クライアントがトークンを取得（または access_denied）できること	✅ 本物の FCM を使って確認
既存の E2E が通ること	✅ 222 成功 / 0 失敗 / 2 Skip（両アプリを起動。送信箱による代替は変えていない）

CIBA の確認の内訳（認証サイトの自己テスト /Home/Saml2OAuth2Starters → fapi_ciba を使用）

	net10.0 版	net48 版
サインイン（PKCE）／端末の登録	✅	✅
フォアグラウンド（画面で受信）→ Allow	✅ OK_NORMAL_END	✅ OK: 正常終了
フォアグラウンド → Deny	✅ OK_ABNORMAL_END	未実施
バックグラウンド（OS の通知 → クリック）→ Allow	✅	✅
PWA としてインストールした状態	✅ サインイン・CIBA の両経路	未実施

確認の過程で分かったこと（文書に記載済み）

• flutter run -d chrome が起動する Chrome（一時プロファイル）では、OS の通知のクリックがアプリに届かない。 バックグラウンドの確認は、-d web-server で配信して普段の Chrome で開く
• flutter run は manifest を生成しない。 DevTools の Installability が「name が無い」等とまとめてエラーになる（manifest.json 自体は正しい）。PWA の確認は flutter build web の出力を配信して行う
• 通知が画面に届くか OS の通知になるかは、アプリの画面が見えているかどうかで決まる（インストールした PWA でも同じ）
• 自己テストの宛先は tanaka@gmail.com に固定されている

別の Issue に分けたもの

• /ciba_authz が、宛先のユーザに端末が登録されていないとき HTTP 500 で JSON でない本文を返す #210：/ciba_authz が、宛先のユーザに端末が登録されていないとき HTTP 500 で JSON でない本文を返す（この確認中に判明）
• 認証デバイスの web 版（PWA）を、スマートフォンから使えるようにする（HTTPS の配信環境） #211：スマートフォンから使えるようにする（HTTPS の配信環境）

残り

• Android / iOS の経路の確認（Android SDK が必要）