おはようございます、ritouです。
何の話か
6/21(火) 19時から、OpenIDファウンデーション・ジャパン主催のイベントがあります。
ここで取り上げられるFedCMについて、3部作ぐらいで 非公式解説 を書いていきます。
- ID連携の課題とFedCMのアプローチ 今回はこれ
- 現状のFedCM実装解説
- FedCM vs OIDC 仕様の差分、RP/IdPの対応、差分解消案
上記イベントでの自分の発表内容は2,3あたりになる予定です。
FedCMとは
FedCMについては、4月末ぐらいにいろいろなドキュメントが公開されました。 英語が読める方はこんな非公式情報を信用せずに、公式なドキュメントを読みましょう。
FedCMで解決したい課題
現在、OpenID ConnectやSAMLを用いたID連携はわりと普及してきましたが、いくつか課題や懸念点があります。 FedCMではID連携で使われているiframe, redirects and cookiesあたりの技術がトラッキング用途のものと区別できないことを問題視しています。
Unfortunately, the mechanisms that identity federation was designed on (iframes, redirects and cookies) can also track users across the web. As the user agent isn't able to differentiate between identity federation and tracking, this makes it difficult to determine when these mechanisms are being used to support identity federation
ID連携の基本動作として、ID連携を利用するサービス(Relying Party, 以下RP)とID連携を提供するサービス(Identity Provider, 以下IdP)の間のリダイレクト、いわゆる「OAuth Dance」があります。 例えば私は Zennに記事を書いております が、Googleアカウントでのログインを始めると一度IdPであるGoogleに遷移してGoogle自体にログインしたり、ログイン中のユーザーからID連携に利用するユーザーを選択したりします。そしてID連携の際にRPに提供される属性情報やリソースアクセスに同意した上でRPに戻ってくるお馴染みのフローのことです。 開発者であれば何が行われているかを割と直感的に理解しやすいかもしれませんが、一般ユーザーはそうではないかもしれません。
このようなID連携フローの利便性を上げるため、いくつかの手法が考えられてきました。 確か2009年とかその辺り...スマホが現在のように普及する前のPC主体の頃、Googleでログインというボタンを押すとポップアップで小さめのGoogleの画面が出てきてログインやユーザー情報の提供への同意が求められ、終わったらそれが閉じて元の画面がログイン状態になるみたいな挙動が実装されました。 なんとなーくおしゃれな感じに立ち上がってくるモーダルの中でログインさせるのではなく、ちゃんとURLを確認可能にする、UIも小さな画面に最適化しつつ現在のログインユーザーやRPに渡される情報などをもれなく表示するといったUX検討が行われ、大手IDプロバイダのSDKなどで実装されるようになりました。
一方で、スマホであればポップアップの挙動が変わるのでリダイレクトでやるしかないかーみたいな話も出てきました。 ID連携だけに止まらないですが、この辺りの利便性を上げる仕組みとして、ブラウザがサポート用のプロンプトを出すような流れが出てきました。 ID連携においてはRPにいる時点でIdPにログイン中のユーザーでログインしますか？みたいなプロンプトを出す仕組みをGoogleがAndroidやWeb向けに提供しています。
私は普段、複数のGoogleアカウントを区別するためにChromeのプロフィールを利用していますが、個人のアカウント以外のところでついうっかり(本当についうっかりです)TwitterのURLを開こうとする とこんな画面になったりします。
これはTwitterのドメイン上でGoogleにログイン中のユーザー情報を含むプロンプトを表示し、ワンタップでユーザー情報をやりとりすることで利便性をあげようみたいな仕組みです。よく見ると、他にもmediumとかいろんなサービスで使われていますよ。
先に紹介したポップアップやこのOne Tapみたいな仕組みを実装しようと思うと、3rd Party Cookieとiframeあたりの話を避けては通れません。Googleのサービスであれば開発者はSDKを使うだけなので意識してなかったりしますが、One Tapもブラウザの設定で3rd Party Cookieをブロックすると動かなくなります。
また、ID連携の仕様の中にはRPとIdPの間でセッション同期、ログアウト同期を行うための仕様があります。これらもフロントチャンネルでの処理ではiframe + postMessage を利用しています。
と、ここまで紹介した3rd Party Cookieを利用する仕組みですが、似たような仕組みで広告周りでユーザーの特定や行動把握のために別ドメインとやりとりしたり、リワードのために一瞬Safariを開いてみたいな実装がよく行われてきました。あれもユーザー情報を同期して何かの最適化を行おうとするものですが、ID連携とは別物です。しかし、ブラウザから見た挙動としてはどうなのでしょうか。これらはとても似ていますというかほぼ一緒、区別できません。
昨今、各ブラウザにはプライバシー保護の名の下に3rd Party Cookieを利用する仕組みを減らしたりブラウザから取れる細かい情報を減らしたりする動きがあります。FedCMを含むChromeのプライバシーサンドボックス構想みたいなのもまさにそれです。しかし上述のとおりID連携の仕組みで3rd Party Cookieに依存するものがあるので、3rd Party Cookieが廃止された世界ではそれらは当然動かなくなります。これはなんとかしないといけませんってなるわけですね。
そこでFedCMですよという話です。
FedCMのアプローチ
FedCMの目的は「3rd Party Cookieを廃止してもID連携の仕組みが動く世の中にしよう。必要に応じてブラウザが仲介することでプライバシー面のリスク低減を目指そう」あたりにあります。
The Federated Credential Management API (FedCM) provides a use case specific abstraction for federated identity flows on the web. This purpose-built API allows the browser to understand the context in which the RP and IdP exchange information, inform the user as to the information and privilege levels being shared and prevent unintended abuse.
具体的には次回以降の記事で書く予定ですがざっくりと
- ID連携にもブラウザが仲介するぞ！
- RPはブラウザのAPIを呼び出してID連携を要求
- ブラウザはIdPに対して1st Party Cookie相当のリクエストを送る
- ブラウザはユーザーのアクション(ユーザー選択や利用の同意)に基づいてIdPから取得した情報をRPへ提供
- ログアウトやID連携の無効化などもブラウザ経由でRPからIdPに伝えられるようにする
あたりがFedCMの現在のスコープとなっています。
ブラウザが仲介して1st Party Cookieとしてリクエストを行う部分については上記3rd Party Cookie廃止の流れへの対応そのものですが、IdPとしても他のドメインからセッションCookieを参照できなくできることはセキュアになるために喜ばしいことでしょう。 ユーザーアクションに基づいてRPに情報開示が行われる部分は既存とそれほど変わらない気はしますが、その辺り配慮してますと言うのはなんとなく伝わってきます。
実装面で言うと、WebAuthnやWebOTPも同様なのですが、ブラウザがプロンプトなりを出してくれる仕組みの場合はJavaScriptなどでしっかりSDKを作り込まなくても比較的容易にRPが実装可能(もちろんそれをラップしてSDKを提供するのはあり)と言うのが大きいでしょう。
現状のFedCMとChromeの実装状況について、ID連携と書いた部分については上で紹介した One Tap 相当の最低限のログインに必要なユーザー情報のやり取りが実現できるところまで実装されています。PC/Android版のChrome Canaryで動作しますので、次回の記事で紹介します。 正直、ここからOIDC/SAMLがフル互換で動く状態になるまでは時間はかかりそうですが、その辺りの考察も今後記事にする予定です。
次回予告
FedCMの現状の動作と裏でどのような処理が行われているかを説明します。
21日までに3つ記事出せるのだろうか???
ではまた！
