質問: Googleなどが提供しているプラットフォーム、を想定しています。 このImplicitフローをベースに質問させてください。 このフローを実装しているサイトをサイトAとします。悪意のあるサイトをサイトBとします。 サイトAのサービスを利用するユーザーが、悪意のあるサイトBにアクセスしてしまったとします。そこでそのサイトBにおいて、サイトAのログイン用APIに意図せずアクセスさせられてしまい(フローでいうと0番目)、その後、フローの5番目までを実行されてしまい、IDトークンを盗まれてしまう可能性はないのでしょうか?(クロスドメイン制約があるので無理?) 私はIDトークンに含まれるnonceというものの役割を理解していないので、このような質問をしているのかもしれません。nonceというランダムな値がサイトAのサーバーで作成され、その後、OPから帰ってくるIDトークンにも含まれるということは理解しているのですが、それが上述したIDトークンが盗まれてしまった場合にどう機能するのかがわかりません。 混乱の中での質問となり、要領を得ない質問で申し訳ありませんが、よろしくお願いします。
回答: 懸念されているフローは、 1. ユーザーは意図せずメールや様々な手段でサイトBに誘導された 2. サイトBは"サイトAになりすまし"、OPの認可画面を要求するリクエストを送る 3. ユーザーは"サイトAに対して"自分の情報に対するアクセスを許可 4. ユーザーはサイトBに戻され、ID Tokenを取得される というような認識であっていますでしょうか? 基本的に、意図しない戻り先URLにユーザーが戻されるかどうかは、OPのclient管理の実装に依存します。 OPへ送られるリクエストのパラメータにclient_id, redirect_uriの値が含まれています。 RPがOPに事前にアプリケーションを登録するのが一般的であり、この際にredirect_uriを設定します。 OPによりその組み合わせの検証が正しく行われ、OPがユーザーをサイトAにのみ戻すような実装が必要となります。 ここでサイトA側が気を付けることとしては、 * OPに対して必要最小限なURLのみをredirect_uriに登録する * redirect_uriがオープンリダイレクタとして動作しないようにする(client_id, redirect_uriの検証が行われてもサイトBに誘導される可能性がある) というあたりです。 ID Tokenの検証に関しては、どちらかというと、サイトAに戻るリクエスト(仕様ではAuthentication Response)を検証することが目的となります。 1. 悪意のあるユーザーが自らのID Tokenをパラメータに付与したURLを生成し、別のユーザーにアクセスさせる 2. サイトAはID Tokenの検証を行って、不正なリクエストをはじく という流れです。こちらの詳細について気になる場合は、別途説明します。