0
ユーザーがログインするたびに、新しいaccess_tokenと新しいrefresh_tokenが追加されます。セキュリティでリフレッシュトークンを実装する方法は？
彼のaccess_tokenが期限切れになったとき、彼はrefresh_tokenを使用して新しいaccess_tokenを取得します。攻撃者が何とかその後、OAuth 2.0のdocumentationによると...彼のrefresh_tokenへのアクセスを取得した場合
：
認証サーバは、新たなリフレッシュトークンは、すべてのアクセス で発行されているリフレッシュトークン 回転を採用することができトークンリフレッシュ応答。以前のリフレッシュ・トークンは無効にされますが、承認サーバーによって保持されます。 リフレッシュトークンが改ざんされ、その後に攻撃者と正規のクライアントの両方によってリフレッシュトークンが使用された場合、そのうちの1人は無効化されたリフレッシュ トークンを提示し、承認サーバーに違反を通知します。
任意のrefresh_tokenが二回使用されているのであれば、基本的に、私は攻撃に気づくでしょう。
しかし、正当なユーザーがリフレッシュトークン（攻撃者によって盗まれたもの）を使用しない場合はどうなりますか？正当なユーザーがそれを検出することなく、攻撃者は何度もログインして更新することができます。
まれな状況のようですか？夕食のために私のところに来て、コンピュータでログインして、あなたのrefresh_tokenとaccess_tokenを取得し、このrefresh_tokenをもう一度使うことはないでしょうか？誰も攻撃に気付くことはありません。
これを解決するにはどうすればよいですか？
もちろん、私はクライアントアプリケーションを意味しました！その後、あなたは "クライアントの秘密"と言いますが、それがjavascriptアプリケーションの場合、どうすればそのようなことに対処できますか？私はそれについてのリソースを見つけることはありません。夕食はパスタ。 – lapin
javascriptアプリケーションはクライアントの秘密を保持できないため、javascriptアプリケーションでリフレッシュトークンを発行しない暗黙の許可タイプを使用する必要があります。パスタは良い:) – iandayman
それでは、どのモバイルアプリも、どのように認証を得ているのですか（秘密裏に2度質問することなく）。 Authorization ServerとResouce serverは、私たちが構築したのと同じサーバーです。暗黙的なフローとは、更新トークンがないことを意味します。 – lapin