[https://www.youtube.com/watch?v=99874h0Sd54:embed:cite]
本動画では、令和3年度春期情報処理安全確保支援士試験の午後Ⅰ問1を題材に、OAuthを用いたソーシャルログインの安全な実装について解説します。S社とT社のID連携事例を通じ、認可コードグラントの流れや、そこで発生しうる脆弱性、およびその対策について詳しく学びます。実務におけるセキュリティ設計や、試験対策として必須の知識を効率よく習得できる内容となっています。 本動画の学習の核となるのは、OAuth 2.0を用いたソーシャルログインの実装におけるセキュリティ設計の詳細です。まず理解すべきはID連携におけるメリットとリスクのトレードオフであり、自社で多要素認証を一から開発するコストを削減できるという利点がある一方で、連携先であるTサービスに障害が発生した際には自社のSサービスも利用不可能になるという可用性の観点での欠点を考慮する必要があります。次にOAuthにおける三つの主体、すなわち利用者、連携元のSサービス、そして連携先のTサービスの役割分担を整理し、特に認可コードグラントと呼ばれるフローにおいて、利用者が直接アクセストークンを受け取るのではなく一度認可コードを介してサーバ間でトークンを交換する手順の意味を把握することが求められます。この仕組みの隙を突く攻撃手法として、攻撃者が自身の認可コードを含んだ罠リンクを作成し被害者に踏ませることで、被害者のブラウザ上のセッションを攻撃者のアカウントとしてログインさせてしまう攻撃シナリオについて解説します。この攻撃が成功すると、被害者がアップロードした重要ファイルが攻撃者のアカウント領域に保存され、結果として攻撃者がそのファイルをダウンロードできてしまうという情報漏洩につながります。この攻撃を防ぐための技術的対策としてstateパラメータの重要性を説きます。これはSサービスが認可リクエスト時に生成する推測困難な値であり、認可コードを受け取る際にその値が自身が発行したものと一致するかを確認することで、一連のシーケンスの整合性を担保し攻撃を防ぐ役割を果たします。さらに設計上の原則として、必要最小限の権限のみを要求するという考え方が不可欠であり、単なる認証目的の連携であれば投稿権限などの不要なスコープを要求せず、ID取得権限のみに絞ることでリスクを低減させます。最後に、アクセストークンを取得することだけが認証の完了ではなく、そのトークンを用いて取得したTサービスのIDがSサービスのデータベースに正規に登録されているかを確認するという検証ロジックの実装も極めて重要な学習ポイントとなります。
