公式ドキュメントに書いてあり、Firebaseからもメールなどで通知されていることではあるのですが、意外と見落としたままになっているかもしれない情報なので、啓蒙の意味も込めて記事にします。
結論
Firebase AuthのJavaScript SDKを使っている場合、今年6月までに以下のドキュメントに従った対応をしないとChrome/Edgeでリダイレクトログインが動かなくなります。
サードパーティのストレージ アクセスをブロックするブラウザで signInWithRedirect を使用する場合のベスト プラクティス
必要な対応
公式ドキュメントにある対応選択肢を、補足や注意点も含めた形で以下に焼き直してみます。
ポップアップ形式のログインでもいい場合
同一タブ内でリダイレクトしてログインする形式から、ポップアップウインドウを開いてログインする形式に切り替えましょう。 （公式ドキュメントの「オプション2」）
こちらが一番手軽な選択肢ではあります。
注意点
ユーザー環境や設定によってはポップアップブロックが作動し、ログイン用のポップアップが表示されない可能性があります。特にモバイル環境、中でもWebViewだと顕著な懸念だと思います。
ポップアップ形式のログインを避けたい場合
ポップアップブロックの懸念があるためポップアップ形式のログインを避けたい場合は、公式ドキュメントにあるとおり、以下のいずれかの方法をとることになります。（オプション5については省略します）
- アプリケーションをFirebase Hostingでホスティングしている場合
- 上記に当てはまらないが、アプリケーションのドメインにリバースプロキシを設定できる場合
- → 公式ドキュメントの「オプション3」
- おそらくこの方法をとるケースが一番多いのではないかと思っています
- 上記どちらにも当てはまらない場合
注意点
これらの方法をとる場合、いずれにしても認証後にリダイレクトされるURLも変わることに注意が必要です。
リダイレクトされるURLが変わるため、利用しているOAuthプロバイダやIDプロバイダ側に設定している「承認済みリダイレクト URI（ACS URL）」の値の変更も必要になります。
公式ドキュメントでいうと、オプション1の中に記載されている 「OAuth プロバイダの承認済みリダイレクト URI のリストに新しい authDomain を追加します。」 という部分です。
場合によってはこの作業がとても大変になるケースがあります。
それが アプリケーションがユーザー側のIDプロバイダを利用したOIDC/SAMLログインを提供しており、ユーザー側のIDプロバイダに「承認済みリダイレクト URI（ACS URL）」としてFirebase AuthのデフォルトURL https://<project>.firebaseapp.com/__/auth/handler を設定してもらっているケース です。
理由は後述しますが、 https://<project>.firebaseapp.com/__/auth/handler にもリバースプロキシをかけて https://<app-domain>/__/auth/handler としてアクセスしアプリケーションとSameOriginにすることで問題回避するという方法なので、ユーザー側のIDプロバイダの値も後者のURLへ設定変更してもらう必要があります。
対象のIDプロバイダがこのACS URLを複数設定できる仕様であれば、移行期間中は新旧両方を登録しておいてもらい、その間に移行作業を進めることができるのですが、IDプロバイダによってはACS URLをひとつしか設定できないものもあります。
その場合はアプリケーション側の変更のデプロイとユーザー側のIDプロバイダの設定変更のタイミングがずれている期間、リダイレクト先のURLの不整合によりOIDC/SAMLログインが失敗することになるでしょう。Feature Flagなど何らかの方法でタイミングを合わせられるようにする工夫が必要になるかもしれません。
マルチテナント式のプロダクトなどで対象のIDプロバイダが複数ある場合などは、リバースプロキシの設定工数よりもこちらの連絡・調整工数のほうがずっと膨らむ可能性があります。ここを見誤るとデッドラインの2024年6月に間に合わなくなる可能性もあるため、早めに現状や必要な作業を把握しておくのがおすすめです。
実際に弊社でも、沢山のお客様にこちらの設定変更へのご協力をいただきました。ご協力への感謝と共に、以下の教訓を得ました。
教訓
そもそも社外へお渡しする値については、何かあった時にも向き先をこちら側だけでコントロールできるように最初から自前のドメインにしておくのが良い選択ですね。今回の件が出る前から元々そのような判断と運用をできている方がいたらとても聡明だと思います。
だいたい一度踏んだら以降はその運用が心に刻まれるけど、踏むまでは意外と気が回らないなあと思います。ドメインまわりの運用は後から気付く学びが多い。
なんで動かなくなるの？
この記事で伝えたかったことは上記の「注意点」が9割なのですが、そもそもなぜ動かなくなるのかという背景の推測も興味のある方向けに簡単に書いておきます。
Firebase Authのリダイレクトログインは、
- ユーザーがIDプロバイダで認証する
- Firebase Authのページにリダイレクトされる
- その際に認証情報をFirebase AuthのページのSession Storageに保存する
- アプリケーションのページにリダイレクトされる
- その際にFirebase Authのページをiframeでアプリケーションに埋め込み、Session Storageの値を読み出してpostMessageなどで親フレームのアプリケーション側に伝える
という仕組みになっているのではないかと推測しています。
そうである場合、今までは 2のSession Storageと 3 のSession Storageの間で値を共有できていたのですが、去年までに各ブラウザに実装された 3rd Party Storage Access の制限により、トップレベルのStorageとCross-Origin iframeのStorageは分割され、値を共有できなくなりました。これにより動かなくなるのだと推測しています。
これはStorage Partitioningと呼ばれています。もっと詳しく知りたい方はこちらのドキュメントを参照してください。
ポップアップログインのほうはポップアップウインドウ側でFirebase Authのページを開いた際にそこから直接親ウインドウへpostMessageが可能なので、Session Storageを経由する必要がなく、影響を受けないのだと思います。
なんで今Chrome/Edgeでは動いてるの？
去年突然Firefox/Safariでリダイレクトログインが動かなくなったのは、それぞれのブラウザにStorage Partitioningが実装されたからであろうことが理解できるようになりました。
しかし、Storage Partitioningは既にChrome/Edgeにも実装されています。にも関わらず、なぜ今Chrome/Edgeでリダイレクトログインが動いているのでしょうか？
その答えは「Firebase Authが、Session StorageのPartitioning適用を先延ばしにするOrigin Trial DisableThirdPartySessionStoragePartitioningAfterGeneralPartitioning を利用しているため」です。
このOrigin Trialについてはドキュメントがあります。
また、直接Firebase Authのページ https://<project>.firebaseapp.com/__/auth/handler を開いてDevToolsを見ることでも同Origin Trialの適用を確認できます。
このOrigin TrialによってFirebase AuthのページにはStorage Partitioningの適用に猶予期間が設けられており、現在はその猶予期間中ということですね。
ちなみに同Origin Trialのページには End date: 2024年9月4日 とあるのですが、Firebaseの公式ドキュメントには 2024年6月18日以降〜 という記載になっています。この期日の差はよくわかっていないです。が、早い方の表記に足並みを揃えておくほうが安全かと思います。
おすすめしたいこと
今回の件を踏まえ、Webアプリケーション開発者の同志におすすめしておきたいのが以下です。
3rd Party Cookie無効化を適用したブラウジング
今回紹介したStorage Partitioningによる挙動変更は既に去年から適用が進んでいますが、これから本格的に適用されていく変更もあります。それが3rd Party Cookie周りの挙動変更です。
こちらはChrome/Edgeで2024年1月より1%のユーザーから段階的に適用されており、今年の秋頃には全ユーザーへ適用される予定になっています。（スケジュール）
いつかは適用されるものなので、Webアプリケーション開発者は先んじて自分のブラウザへ適用状態にした上で自分のアプリケーションを触っておくことをおすすめします。 chrome://flags/#test-third-party-cookie-phaseout からEnabledにしてブラウザを再起動すると適用できます。
もしも自分のアプリケーションの挙動が変わっていたら、今も一部のユーザーは同じことになっているし、今年の秋頃には全ユーザーがそうなる、ということです。起きうる影響は早めに把握しておきましょう。
依存する別サイトのOrigin Trial状況の確認
今回のように、本来は動かないアプリケーションコードが、依存する別サイトの申請しているOrigin Trialによる猶予期間で動き続けてしまっていることで影響に気付くのが遅れるケースには要注意です。Origin Trial終了後に動かなくなったことに気付いても、そのときには申請できる猶予措置がなくなっています。
別サイトを利用したプロダクトを提供している場合は、DevToolsでのOrigin Trialの確認方法 で別サイト側のOrigin Trial状況についても確認しておきましょう。 Origin Trialが申請されていたら、それがどんな挙動変更を延長するものなのか、切れたら何が起こるのか把握しておくことをおすすめします。
特に、認証状態を持つ自社プロダクトを別サイトへiframe埋め込みする形で提供しているケースでは、本来影響が出ているはずの可能性が非常に高いです。
終わりに
2024年はWebにとって激動の年です。Storage Partitioningを含む3rd Party Cookie関連規制により、今まで動いていた様々な仕組みがそのままだと動かなくなっていきます。
なぜそんな変化をする必要があるのか？他にどんな変化があるのか？についてはぜひ以下のアドベントカレンダーの記事を一通り読んでみてください。ものすごく解像度が上がると思います。
リダイレクト先URLの変更が大変だった、Origin Trialで延命されていることに気付かなかった、などは実際に自分が直近踏んできたあれこれでした。
記事にすることで同じ状況の誰かが少しでも近道をして問題を解決できる助けになれれば幸いです。
激動の2024年、情報や知見を共有し合って乗り越えていきましょう！
Discussion