OAuthサーバーは複数回要求された `refresh_token`をどのように処理しますか？
OAuth2認証プロセスでは、更新トークンは1回だけ使用する必要があります。 refresh_tokenを使用すると、新しいaccess_tokenおよび新しいrefresh_tokenが返されます。
これも RFC6819仕様 にあります：
5.2.2.3。トークンローテーションの更新
更新トークンのローテーションは、異なるアプリ/デバイスから同じ更新トークンを並行して使用する試みを自動的に検出して防止することを目的としています。これは、トークンがクライアントから盗まれ、その後、攻撃者と正当なクライアントの両方によって使用された場合に発生します。基本的な考え方は、古い更新トークンを使用してアクセストークンを取得する試みを検出するために、更新要求ごとに更新トークンの値を変更することです。承認サーバーは、攻撃者または正当なクライアントがアクセスしようとしているかどうかを判断できないため、そのようなアクセスが試行された場合、有効な更新トークンとそれに関連付けられたアクセス承認の両方が取り消されます。
OAuth仕様は、トークンの応答により、許可タイプが「refresh_token」のリクエストであっても、承認サーバーが新しい更新トークンを返すことができるという点で、この手段をサポートしています。
注：現在有効な更新トークンの使用を保証する必要があるため、この対策はクラスター環境で問題を引き起こす可能性があります。このような環境では、他の対策がより適切な場合があります。
これにより、認証サーバーはrefresh_tokenが侵害されたことを認識できます。これは、一度だけ使用する必要があるためです。同じrefresh_tokenの新しい更新要求が認証サーバーに届いた場合、何か問題が発生していることがわかります。
サーバーがそのようなシナリオに対処するための適切な方法は何でしょうか？私の推測では、その特定のクライアントの少なくともすべてのaccess_tokensを直接無効にする必要があります。
OAuth2サーバーは通常、同じrefresh_tokenを使用して複数のリクエストをどのように処理しますか？
アクセストークンの無効化
特定のclient_idのすべてのアクセストークンを無効にすることはできません。 client_idは通常、1つのアプリケーションにバインドされていますが、このアプリはより多くのユーザーによって使用されています。また、1人のユーザーでも異なるデバイスから同じアプリを使用できます。更新トークンは一種のセッションを作成します。特定のアプリ、ユーザー、デバイスに固有である必要があります。さらに、クライアントはより狭いスコープで更新トークンを呼び出す場合があります。この場合、より広いスコープで古いアクセストークンを無効にしたくない場合は、クライアントは引き続きそれを使用できます。
私の限られた経験では、OAuthサーバーは更新トークン呼び出しでアクセストークンを無効にしません。アクセストークンは短命であり、時間内に期限切れになります。
トークンの複数のリクエストを更新します
RFC6819セクション6 ：を参照してください。認証サーバーは新しい更新トークンを発行できます...認証サーバーは、クライアントに新しい更新トークンを発行した後、古い更新トークンを取り消すことができます。 スペック。ある程度の自由を許可するため、実装は異なります。非常に安全な実装は、新しい更新トークンを発行し、毎回古いトークンを無効にすることです。ただし、これにより、同時呼び出し（マルチスレッドアプリなど）で問題が発生します。そのため、一部のサーバーには、1つの長続きする更新トークンしかありません（実装が単純で、安全性が低くなります）。他の人は、新しい更新トークンが発行された後、古い更新トークンを短時間（たとえば、2分）有効に保ちます。