web-dev-qa-db-ja.com

更新トークンはどのように役立ちますか?

基本的な疑問があるか、基本的に何かを見逃しているようです。 Androidアプリについて話す場合、リソース/ APIへのアクセスは、アクセストークンと更新トークンを使用して保護されます(OAuth = 2.0)。

私が理解していることから、これはそれがどのように機能するかです:

  1. ユーザーはアプリを開き、ログイン認証情報を提供します。
  2. アプリはPOSTリクエストをサーバーに送信し、サーバーはアプリにアクセストークン(ランダムで推測できないトークン)を発行します。
  3. アプリはこのアクセストークンをローカルストレージ(sqlite db /共有設定など)に安全に保存し、他のすべてのAPI呼び出しでこのトークンを送信して、リソースへのアクセスが承認されていることをサーバーに通知します。
  4. このアクセストークンにも有効期限があります。そのため、アクセストークンが侵害された場合でも、どういうわけか、攻撃ウィンドウは小さくなります。
  5. これが発生した場合、ユーザーはログイン資格情報を貸し出し、承認されたアクセストークンを再度取得する必要があります。これは、少なくともモバイルアプリの場合、ユーザーエクスペリエンスが悪い(許容できない)ものです。
  6. したがって、この問題を解決するために、最初にアクセストークンと共にアプリに発行されるrefresh tokenがあります。この更新トークンは非常に長期間有効な特別なトークンであり、アクセストークンの有効期限が切れるとすぐにサーバーに新しいアクセストークンを要求するため、ユーザーがログイン資格情報を再入力して新しい承認済みアクセストークン。

今私の質問は:

これにより、APIへの不正アクセスを防止するという元々の問題をどのように解決しますか?私の意見では、実際にはそれをさらに促進します。

アクセストークンが侵害された場合、リフレッシュトークンも同じように侵害される可能性が高いのではないでしょうか。また、更新トークンは非常に長期間有効なトークンであるため、攻撃者はそれを使用して(更新トークンの有効期限が切れるまで)、新しい承認済みアクセストークンを生成し続けることができます。あれは正しいですか ?

これを理解してください。

28
qre0ct

更新トークンの主な利点は、セキュリティが侵害されているかどうかを簡単に検出できることです。

次の2つのシナリオを検討してください。

  1. 単一の永続的な認証トークンが使用されます。
  2. 短い期間の認証トークンが使用され、長期間持続する更新トークンは、前のトークンが期限切れになると、定期的に新しい認証トークンを要求します。

シナリオ1では、認証トークンが危険にさらされている場合、だれもこれを検出するのは難しく、不正なアクセスが無期限に続く可能性があります。

シナリオ2では、認証トークンのみが危険にさらされている場合(更新トークンも危険にさらされていない場合)、トークンが期限切れになるまでしか継続できません。

シナリオ2では、更新トークンが危険にさらされている場合、更新トークンが呼び出されると、その更新トークンを使用して生成された他のすべての認証トークンが無効になるため、一度に1つのパーティーのみが(更新トークンごとに)APIを使用できます。その結果、複数のユーザーが新しいトークンを生成してお互いの認証トークンを繰り返し無効にすることになります。 authトークンの有効期限が切れる前に更新が行われるため、APIは違反を検出でき、更新トークンを即座に取り消すことがわかっています。

23
TTT