9578


Open ID Connectについて勉強中です。  
Client = WEBブラウザ、RP = WEBサーバー、OP = Googleなどが提供しているプラットフォーム、を想定しています。

[この](http://image.slidesharecdn.com/openidconnectintroseptember2013-131010025559-phpapp02/95/openid-
connect-20139-8-638.jpg?cb=1381391826)Implicitフローをベースに質問させてください。

このフローを実装しているサイトをサイトAとします。悪意のあるサイトをサイトBとします。  
サイトAのサービスを利用するユーザーが、悪意のあるサイトBにアクセスしてしまったとします。そこでそのサイトBにおいて、サイトAのログイン用APIに意図せずアクセスさせられてしまい（フローでいうと0番目）、その後、フローの５番目までを実行されてしまい、IDトークンを盗まれてしまう可能性はないのでしょうか？（クロスドメイン制約があるので無理？）  
私はIDトークンに含まれるnonceというものの役割を理解していないので、このような質問をしているのかもしれません。nonceというランダムな値がサイトAのサーバーで作成され、その後、OPから帰ってくるIDトークンにも含まれるということは理解しているのですが、それが上述したIDトークンが盗まれてしまった場合にどう機能するのかがわかりません。

混乱の中での質問となり、要領を得ない質問で申し訳ありませんが、よろしくお願いします。


CC BY-SA 3.0
2015-04-26T15:16:41.780
9574
2015-04-27T00:25:40.067
2015-04-26T22:35:39.150
3639
64
question
oauth
Open ID Connectにおいて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の検証を行って、不正なリクエストをはじく  
という流れです。こちらの詳細について気になる場合は、別途説明します。


CC BY-SA 3.0
2015-04-27T00:25:40.067
9578
2015-04-27T00:25:40.067
9502
9574
answer