Facebook Login のリダイレクト URL が完全一致制限になるという話(追記あり)

Facebook Developer News で今日「Enhanced Security for Facebook Login with Strict URI Matching」という記事が出ていたが、来年 3 月以降、Facebook Login の戻り先リダイレクト URL が Facebook app で設定したものに完全一致した URL にのみリダイレクトするように仕様変更されることになった。

これに伴い、対応が必要になる場合は

Strict Redirect URI Matching

In 90 days, we’re making a security update to Facebook Login that will invalidate calls from URIs not listed in the Valid OAuth redirect URIs field of your Facebook Login settings.

といったアラートが送信されているかと思う。

Table of Contents

仕様変更点

OAuth 2.0 で Facebook Login を実装する場合、ブラウザのリダイレクト遷移で認証および認可が行われるが、Facebook 側で認証・認可して結果を戻す場合もリダイレクトで行われる。この際、URL にパラメータ付与されたトークンで認証結果を取得するが、リダイレクト先をハイジャックすることでエンドユーザのアクセストークンを奪取することができた。

これを防ぐために、Facebook app 側設定でリダイレクト先 URL を前方一致で制限することができたが、今までは

設定しなくても ok だった。
設定したとしても前方一致のみだった。

ため、例えば https://example.com/ レベルの設定でも問題なかった。

これだとハイジャックしてアクセストークンを奪取することが可能になるため、3 月以降、

原則としてリダイレクト先 URL の制限は必須。
設定する URL は完全一致のみ。

に変更される。ほぼ使われていない mixi の OAuth がこういった実装だが、これにあわせてくると言ってよい。

対応

Facebook app で「Strict Redirect URI Matching」というタイトルのアラートが来ている場合は変更が必要な場合なので、以下の通り変更する必要がある。逆に言えば、アラートが来ていなければ、現時点では対応の必要はない。

基本方針

対応としては、リダイレクト URL を Facebook app 側に完全一致で入力することになる。

このアラートを受け取った場合は、ほぼほぼ

そもそも入力していない。
テスト環境と本番環境で URL が異なるため、前方一致でごまかしている。

のどちらかだと思われる。

後者の場合でも複数の URL が設定できるので、必要な分だけ入力しておけばいい。

認証前に受け取ったパラメータを認証後に引き継ぎたい場合

特に CSRF (Cross-Site Request Forgery) 対策で認証シーケンスの一貫性を担保する意味で認証前にランダムなトークンを発行し、それをリダイレクト先に引き継ぐことでセッション内に保存したトークンとリダイレクト先で受け取ったトークンを照合している場合があるかと思う。
こういう場合は、CSRF 対策用のワンタイムトークンを state パラメータに引き渡すとよい。

これ以外のケース、例えば Google Analytics の utm などを認証後にリダイレクトするページに引き継ぎたいケースなどについては、セッションに格納しておくのが常道で普通はそういった実装をしているだろうが、リダイレクトの間を引き回している場合は修正が必要になる。

まとめ

今回の実装は、OAuth で問題となる部分の対応として普通の実装だと思う。対応もほぼすべてのケースでコードの書き換えは発生しないはずなので、早めに対応を終わらせたい。

追記

この問題、Facebook 新機能あるあるのバグがあるらしく、バグチケットが切られていた。正しく設定したはずなのに問題がある場合は、このバグの修正を待って試すといいかと思う。

1/25 追記

上記バグは解消済の模様。

仕様変更点

対応

基本方針

認証前に受け取ったパラメータを認証後に引き継ぎたい場合

まとめ

追記

1/25 追記

参考

関連

投稿者: Kenta ONISHI