「Googleでサインイン」や「Appleで続ける」は10年以上にわたりフェデレーテッドログインを支えてきました。これらはオンボーディングの摩擦を取り除き、パスワード疲労を解消し、匿名トラフィックをアカウントに変換するため、ほぼすべての消費者向けサインアップページに設置されています。しかし、その基盤となる仕組みに問題があります。
これらのボタンはサードパーティCookieで動作しています。従来のソーシャルログインフローは、プライバシー規制当局が長年封じ込めようとしてきた、まさにそのクロスドメインの仕組みに依存しています。
「従来のソーシャルログインフローは、プライバシー規制当局が長年封じ込めようとしてきた、まさにそのクロスドメインの仕組みに依存しています。」
Safariは2020年からデフォルトでサードパーティCookieをブロックしており（Intelligent Tracking Prevention）、Firefoxも2019年からブロックしています（Enhanced Tracking Protection）。これにより、ウェブの約半分がすでにCookieを使用できない状態になっています。
Chromeの状況はより複雑です。Googleは2024年に強制的な廃止を撤回し、スイッチを切り替えるのではなくユーザー選択モデルに移行したため、誰もがロードマップを組んでいた「Cookie-pocalypse」の期限は実際には到来しませんでした。ただし、これは猶予期間と解釈すべきではありません。主要な2つのエンジンがデフォルトでブロックされており、Chromeのシークレットモードもデフォルトでブロックされています。広告ブロッカーや同意疲労も増加しており、Cookieは期限が発表されるかどうかにかかわらず、徐々に失われつつあります。これに依存するログインの仕組みは、時間に限りがあると言えます。
FedCM（Federated Credential Management）は、その仕組みがなくなった後もフェデレーテッドログインを維持するために構築された標準です。W3Cと主要なブラウザエンジンが、クロスサイトトラッキングなしでフェデレーテッドIDフローを実行するブラウザネイティブのAPIとして開発しました。
実際の仕組み
移行はアーキテクチャ上のものです。従来のフローでは、ソーシャルボタンをクリックすると、IDプロバイダーが自身のCookieを読み取ってユーザーを確認できるように、隠しiframe、リダイレクト、またはポップアップが起動します。この同じチャネルにより、IdPはウェブ全体でユーザーを追跡できます。FedCMは、ブラウザを信頼できる仲介者として中間に配置します。
サイトは1回の明示的なAPI呼び出し、navigator.credentials.get()を通じてIDトークンを要求し、ブラウザが残りの処理を実行します。
- サイトがブラウザにIDトークンを要求します。
- ブラウザは、要求元のサイトから分離された状態で、IdPがホストする設定ファイルからアカウントの詳細を取得します。
- ブラウザはポップアップではなく、ネイティブのサインインプロンプトを表示します。
- 明示的なユーザーの同意により、ブラウザはトークンをサイトのバックエンドに渡してセッションを作成します。
認証とパッシブトラッキングが分離されます。（APIの詳細については、FedCM仕様およびMDNドキュメントを参照してください。）
また、NASCAR問題も解決します。利用可能なすべてのソーシャルログインを追加し続けた結果、サインアップページには競合するブランドのボタンが並ぶことになり、登録はスポンサーデカールで覆われたストックカーと同じような状態になりました。これは認知負荷であり、認知負荷はコンバージョンを損ないます。
「FedCMはボタンの壁をスキップし、適切なアカウントを1つのネイティブプロンプトで表示します。」
ブラウザはすでにユーザーが最後に使用したプロバイダーを把握しているため、FedCMはボタンの壁をスキップし、適切なアカウントを1つのネイティブプロンプトで表示します。
従来のフローとFedCMの比較
実用的な効果はコンバージョンです。追加のクリックや中断されたリダイレクトは、サインアップを試みるユーザーの一定割合を失わせ、モバイルブラウザは従来のフローが依存する二次ウィンドウを頻繁にブロックします。単一のネイティブプロンプトにより、この離脱を防ぐことができます。
「追加のクリックや中断されたリダイレクトは、サインアップを試みるユーザーの一定割合を失わせ、モバイルブラウザは従来のフローが依存する二次ウィンドウを頻繁にブロックします。」
メンテナンス面でも利点があります。標準化されたブラウザUIにより、チームはカスタムのログインコンポーネントの構築や管理から解放され、フローはリファクタリングではなくブラウザのリリースを通じてアップグレードされます。
本番環境での実例
Axel SpringerはOry上でFedCMを数億人のユーザーに導入しています。同社のProduct & Revenue担当ゼネラルディレクターであるThomas Bergemann氏は、その結果を率直に述べています。「登録数が15倍以上増加しました。」（ケーススタディを読む。）
Googleのブラウザを介したサインインに関するテストでも同様の結果が示されています。モバイルデバイスで頻繁にブロックされる、煩わしい二次ウィンドウのステップを排除することで、ユーザーの離脱が減少します。
ShopifyはCookie変更に先駆けてブラウザを介したIDに移行し、厳格でプライバシー重視のモバイルブラウザにおいて、従来のフローが静かに失敗する環境下でもチェックアウトのコンバージョンを安定して維持しました。
Oryでの始め方
ステップ1：バックエンドをCIAMプラットフォームの背後に配置する。 自分で構築する必要はありません。Ory KratosはFedCMのバックエンド側をネイティブに処理し、ブラウザ側のIDアサーションを安全なユーザーセッションに変換します。（Ory FedCM導入ドキュメントを参照してください。）
ステップ2：ソーシャルサインインプロバイダーを設定する。 Ory ConsoleでSocial Sign-Inパネルを開き、IdPを選択してそのFedCM Config URLを入力します。バックチャネルでの信頼検証は自動的に処理されます。
ステップ3：JavaScriptトリガーを埋め込む。 ログイン ページに軽量なスニペットを配置して、サポートを検出し、サポートされていない場合はクリーンにフォールバックします。
if ('IdentityCredential' in window) {
navigator.credentials.get({
identity: {
providers: [{
configURL: 'https://auth.your-business.com/self-service/methods/oidc/fedcm/google',
clientId: 'YOUR_CLIENT_ID',
}]
}
}).then((credential) => {
return fetch('/self-service/methods/oidc/fedcm/login', {
method: 'POST',
body: JSON.stringify({ token: credential.token })
});
}).catch((err) => {
console.error('FedCM flow interrupted, fallback to traditional OIDC:', err);
});
}
ブラウザがFedCMをサポートしていない場合、フローは標準的なOpenID Connectリダイレクトにフォールバックするため、移行中に誰もロックアウトされません。実際のIdPを接続する前にテストしたい場合は、無料のMockFedCMサイトが利用できます。
今後の展望
フェデレーテッドログインはブラウザに移行しつつあり、プライバシーモデルもそれに伴って変化しています。SafariとFirefoxはすでにデフォルトでブロックしており、ChromeはCookieを完全に廃止するのではなく、徐々に失わせる方向に進んでいます。どちらの道も、ソーシャルログインを現状のままにしておくことはできません。
今認証スタックを監査しているチームは、後で他人のスケジュールで壊れたログインロープをデバッグする必要がなくなるでしょう。ブラウザの都合に合わせるのではなく、自分のスケジュールでこの移行を行う方が良いでしょう。
Group Created with Sketch.
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.