[解決済み】OAuth v2には、なぜアクセス・トークンとリフレッシュ・トークンの両方があるのでしょうか？

質問

OAuth 2.0プロトコルのドラフト4.2項では、認証サーバーが、認証に必要な情報を得るために access_token (リソースとの認証に使用される)と同様に refresh_token これは、純粋に新しい access_token :

https://www.rfc-editor.org/rfc/rfc6749#section-4.2

なぜ両方あるのか？なぜ access_token と同じ長さです。 refresh_token を持たず、かつ refresh_token ?

解決方法は？

リフレッシュ・トークンのアイデアは、アクセストークンが侵害された場合、それが短命であるため、攻撃者がそれを悪用するための限られたウィンドウを持つというものです。

リフレッシュ・トークンが漏洩した場合、攻撃者はアクセストークンを獲得するためにリフレッシュ・トークンに加えてクライアントIDとシークレットを要求するため、役に立たない。

とはいえ アクセス/リフレッシュ・トークンを要求する際に、オリジナルのクライアントIDとシークレットも含めて、認可サーバーとリソース・サーバーのすべての呼び出しがSSL上で行われるので、アクセストークンが長寿命のリフレッシュ・トークンとクライアントID/シークレットの組み合わせよりも「妥協しやすい」のかどうか、私にはよくわからないのです。

これはもちろん、認可サーバーとリソースサーバーの両方を制御しない実装とは異なります。

リフレッシュ・トークンの使用法については、こちらのスレッドが参考になります。 OAuth アーカイブ .

リフレッシュ・トークンのセキュリティ上の目的について、上記から引用します。

リフレッシュ・トークンは...長期間のアクセス・トークンの漏洩リスクを軽減します（安全でないリソース・サーバーのログファイル内のクエリ・パラメータ、ベータまたは不十分なコーディングのリソース・サーバーのアプリ、httpsでないサイトのJS SDKクライアントがクッキーにアクセス・トークンを入れる、など）。