ドラフトOAuth 2.0プロトコルのセクション4.2は、承認サーバーがaccess_token（リソースで自分自身を認証するために使用される）と、refresh_token単にを作成するためだけに使用されるを返すことができることを示していますaccess_token：
https://tools.ietf.org/html/rfc6749#section-4.2
なぜ両方あるの？持っていないaccess_token限り、最後だけを作ってみませんか？refresh_tokenrefresh_token
回答:
リフレッシュトークンの考え方は、アクセストークンが危険にさらされている場合、存続期間が短いため、攻撃者はそれを悪用するウィンドウが限られているということです。
攻撃者がアクセストークンを取得するためには、更新トークンに加えてクライアントIDとシークレットを必要とするため、更新トークンが危険にさらされている場合は役に立ちません。
とは言っても、承認サーバーとリソースサーバーの両方へのすべての呼び出しはSSLを介して行われるため、アクセス/更新トークンを要求するときの元のクライアントIDとシークレットが含まれるため、アクセストークンがどのようになるかはわかりません。存続期間が長い更新トークンとclientid / secretの組み合わせよりも妥協が可能です。
もちろん、これは、承認サーバーとリソースサーバーの両方を制御しない実装とは異なります。
更新トークンの使用について説明する良いスレッドは次のとおりです。OAuthアーカイブ。
リフレッシュトークンのセキュリティ目的について述べた、上記の引用：
トークンを更新...は、長期間存続するaccess_tokenリークのリスクを軽減します（安全でないリソースサーバーのログファイル内のクエリパラメーター、ベータ版または不十分にコード化されたリソースサーバーアプリ、https以外のサイトのJS SDKクライアントは、access_tokenをクッキーなど）
Catchdaveによって提供されたディスカッションへのリンクに は、Dick Hardtによって作成された別の有効なポイント （元のデッドリンク）があります。
更新トークンの私の思い出は、セキュリティと取り消しのためでした。<...>
取り消し：アクセストークンが自己完結型の場合、新しいアクセストークンを発行しないことにより、承認を取り消すことができます。リソースは、アクセストークンが有効かどうかを確認するために承認サーバーにクエリを送信する必要はありません。これにより、アクセストークンの検証が簡略化され、複数の承認サーバーのスケーリングとサポートが容易になります。アクセストークンは有効ですが、認証が取り消される時間枠があります。
実際、Resource ServerとAuthorization Serverが同じエンティティであり、ユーザーとそれらのどちらかとの間の接続が（通常）同等に安全である状況では、更新トークンをアクセストークンから分離しておくことはあまり意味がありません。
引用で述べたように、リフレッシュトークンのもう1つの役割は、システムを同時にスケーラブルに保ちながら、ユーザーがいつでも（たとえば、プロファイルのWebインターフェイスを介して）アクセストークンを取り消せるようにすることです。 。
一般に、トークンはサーバーのデータベース内の特定のレコードを指すランダムな識別子にすることも、トークン自体にすべての情報を含めることもできます（確かに、この情報は、たとえばMACで署名する必要があります）。
存続期間の長いアクセストークンを使用したシステムの動作方法
サーバーは、クライアントがトークンを発行することにより、事前定義されたスコープのセット内でユーザーのデータにアクセスできるようにします。トークンを取り消し可能にしたいので、「取り消し」フラグが設定または設定解除された状態でトークンをデータベースに保存する必要があります（そうでない場合、自己完結型トークンでそれをどのように行いますか？）データベースには、len(users) x len(registered clients) x len(scopes combination)レコードと同じだけの数を含めることができます。次に、すべてのAPI要求がデータベースにヒットする必要があります。このようなデータベースに対してO（1）を実行するクエリを作成するのは簡単ですが、単一障害点自体がシステムのスケーラビリティとパフォーマンスに悪影響を及ぼす可能性があります。
存続期間の長いリフレッシュトークンと存続期間の短いアクセストークンを持つシステムがどのように機能するか
ここでは、2つのキーを発行します。データベース内の対応するレコードを持つランダムリフレッシュトークンと、有効期限のタイムスタンプフィールドを含む署名付きの自己完結型アクセストークンです。
アクセストークンは自己完結型であるため、その有効性を確認するためにデータベースにアクセスする必要はありません。トークンをデコードし、署名とタイムスタンプを検証するだけです。
それでも、更新トークンのデータベースを保持する必要がありますが、このデータベースへのリクエスト数は通常、アクセストークンの有効期間によって定義されます（有効期間が長いほど、アクセスレートは低くなります）。
特定のユーザーからのクライアントのアクセスを取り消すには、対応する更新トークンを「取り消された」としてマーク（または完全に削除）し、新しいアクセストークンの発行を停止する必要があります。ただし、更新トークンが取り消されたウィンドウがあることは明らかですが、そのアクセストークンはまだ有効である可能性があります。
トレードオフ
更新トークンは、アクセストークンデータベースのSPoF（単一障害点）を部分的に排除しますが、明らかな欠点がいくつかあります。
窓"。イベント「ユーザーがアクセスを取り消す」と「アクセスが取り消されることが保証されている」の間の時間枠。
クライアントロジックの複雑さ。
更新トークンなし
リフレッシュトークン
この答えが意味をなして、誰かがより思慮深い決定をするのに役立つことを願っています。githubやfoursquareなどのよく知られているOAuth2プロバイダーが、リフレッシュトークンなしでプロトコルを採用していることにも注意したいと思います。
上記のすべての偉大な答えにもかかわらず、私以前にイーベイで働いていたセキュリティー・マスターの学生やプログラマが、私は買い手保護と不正行為に見ていた時に、別のアクセストークンとリフレッシュトークンに言うことができるのがあるとしてベストバランスの嫌がらせユーザとの間の頻繁なユーザ名を/ passwordの入力と、サービスの不正使用の可能性へのアクセスを取り消すための権限を保持する。
このようなシナリオを考えてください。3600秒のアクセストークンのユーザーを発行し、トークンを1日ほど長く更新します。
ユーザーは良いユーザーです。彼は家にいて、あなたのWebサイトで買い物をしたり、iPhoneで検索したりします。彼のIPアドレスは変更されず、サーバーの負荷は非常に低くなっています。毎分3〜5ページのリクエストのように。アクセストークンの3600秒が経過すると、更新トークンを使用して新しいものが必要になります。私たちはサーバー側で、彼の活動履歴とIPアドレスを確認し、彼は人間であると思い、自分で行動します。サービスを引き続き使用するために、新しいアクセストークンを彼に付与します。ユーザーは、更新トークン自体の1日の寿命に達するまで、ユーザー名/パスワードを再入力する必要はありません。
ユーザーは不注意なユーザーです。彼はアメリカのニューヨークに住んでいて、ウイルスプログラムをシャットダウンし、ポーランドのハッカーにハッキングされました。ハッカーがアクセストークンと更新トークンを取得すると、ユーザーを偽装してサービスを使用しようとします。しかし、短期間のアクセストークンの有効期限が切れた後、ハッカーがアクセストークンを更新しようとすると、サーバー上で、ユーザーの行動履歴に劇的なIPの変化があることに気付きました（この人は米国にログインして、ポーランドのアクセスを更新しています）たったの3600年代???）更新プロセスを終了し、更新トークン自体を無効にして、ユーザー名/パスワードの再入力を求めます。
ユーザーは悪意のあるユーザーです。彼は、ロボットを使用して毎分1000回APIを呼び出すことにより、サービスを悪用することを目的としています。彼は、3600秒後までアクセストークンを更新しようとするまで、そうすることができます。私たちは彼の行動に気づき、彼は人間ではないかもしれないと思いました。更新プロセスを拒否して終了し、ユーザー名/パスワードの再入力を求めます。これにより、ロボットの自動フローが壊れる可能性があります。少なくとも彼は不快になります。
更新トークンが完全に機能したことは、仕事、ユーザーエクスペリエンス、盗まれたトークンの潜在的なリスクのバランスをとろうとしたときに確認できます。サーバー側のウォッチドッグは、IPの変更、API呼び出しの頻度だけでなく、ユーザーが優れたユーザーであるかどうかを確認できます。
別の言い方をすると、基本的なIPウォッチドッグまたはその他の手段を各API呼び出しに実装することにより、盗まれたトークン/サービスの悪用によるダメージ制御を制限することもできます。ただし、ユーザーに関するレコードを読み書きする必要があり、サーバーの応答が遅くなるため、これはコストがかかります。
これらの答えのどちらも、更新トークンが存在するという中心的な理由に到達しません。もちろん、クライアントの資格情報を認証サーバーに送信することで、常に新しいアクセストークン/更新トークンペアを取得できます。これにより、最初にそれらを取得できます。
そのため、更新トークンの唯一の目的は、ネットワーク経由で認証サービスに送信されるクライアント資格情報の使用を制限することです。アクセストークンのttlが短いほど、新しいアクセストークンを取得するためにクライアントの資格情報を使用する必要がある頻度が高くなるため、攻撃者がクライアントの資格情報を危険にさらす機会が多くなります（ただし、これは非常に困難です）それらを送信するために非対称暗号化が使用されています）。したがって、使い捨てのリフレッシュトークンがある場合は、クライアントの資格情報を損なうことなく、アクセストークンのttlを任意に小さくすることができます。
混乱を解消するには、クライアントシークレットとユーザーパスワードの役割を理解する必要があります。これらは非常に異なります。
クライアントは、あるアプリ/ウェブサイト/プログラム/ ...、したいサーバー、に裏打ちされた認証を行うユーザーをサードパーティの認証サービスを使用することによって。クライアントシークレットは、このクライアントと認証サーバーの両方が認識している（ランダムな）文字列です。このシークレットを使用して、クライアントは認証サーバーで自身を識別し、アクセストークンをリクエストするための承認を受け取ることができます。
初期アクセストークンと更新トークンを取得するには、次のものが必要です。
ただし、更新されたアクセストークンを取得するには、クライアントは次の情報を使用します。
これは明らかに違いを示しています。更新時に、クライアントはクライアントシークレットを使用してアクセストークンを更新するための承認を受け取るため、ユーザーID +パスワードの代わりに更新トークンを使用してユーザーを再認証できます。これにより、ユーザーはパスワードを再入力する必要がなくなります。
これは、クライアントIDとシークレットが不明であるため、更新トークンを紛失しても問題がないことも示しています。また、クライアントIDとクライアントの秘密を秘密にしておくことが重要であることも示しています。
この回答は、OAuth 2の標準的な本文のメーリングリストを介したJustin Richerからのものです。これは彼の許可を得て掲載されています。
更新トークンの存続期間は（AS）承認サーバー次第です。有効期限が切れたり、取り消されたりする可能性があります。更新トークンとアクセストークンの違いはオーディエンスです。更新トークンは承認サーバーにのみ戻されます。アクセストークンは（RS）リソースサーバーに送信されます。
また、アクセストークンを取得しただけでは、ユーザーがログインしたことにはなりません。実際には、ユーザーがそこにいなくなった可能性もあります。これは、実際には更新トークンの使用目的です。アクセストークンを更新すると、ユーザーに代わってAPIにアクセスできるようになります。ユーザーがそこにいるかどうかはわかりません。
OpenID Connectは、アクセストークンからユーザー情報を提供するだけでなく、IDトークンも提供します。これは、ASやRSではなく、クライアント自体に送信される個別のデータです。OIDCでは、新しいIDトークンを取得できる場合にのみ、プロトコルによって実際に「ログイン」している人を考慮する必要があります。さわやかでは十分ではないようです。
詳細については、http：//oauth.net/articles/authentication/を参照してください。
クライアントはさまざまな方法で危険にさらされます。たとえば、携帯電話のクローンを作成できます。アクセストークンの有効期限が切れると、クライアントは承認サーバーへの再認証を余儀なくされます。再認証中に、承認サーバーは他の特性をチェックできます（IOWはアダプティブアクセス管理を実行します）。
更新トークンを使用すると、クライアントのみが再認証を行うことができます。再認証を行うと、多くのユーザーがやりたくないとユーザーが対話するようになります。
更新トークンは、通常のWebサイトが1時間程度後に定期的にユーザーを再認証することを選択する可能性のある場所（銀行サイトなど）と基本的に同じ場所に収まります。ほとんどのソーシャルWebサイトはWebユーザーを再認証しないため、現在はあまり使用されていません。なぜクライアントを再認証するのでしょうか。
refresh_tokenがなく、refresh_tokenがない限り、access_tokenを長持ちさせるだけではどうですか。
すばらしい回答に加えて、他の人々が提供したのは、更新トークンを使用する理由と、クレームとの関係です。
各トークンにはクレームが含まれており、クレームにはユーザー名、役割、またはクレームを作成したプロバイダーのあらゆるものが含まれます。トークンが更新されると、これらの要求が更新されます。
トークンをより頻繁に更新すると、IDサービスに明らかに負担がかかりますが、より正確で最新のクレームが得られます。
BTの答えをさらに簡略化するには：通常、ユーザーが資格情報を再度入力する必要はないが、権限を取り消すことができるようにするには、更新トークンを使用します（更新トークンを取り消すことにより）。
アクセストークンを取り消すことはできません。リフレッシュトークンのみを取り消すことができます。
この答えは、2人の上級開発者（John BraytonとDavid Jennes）の助けによってまとめられました。
更新トークンを使用する主な理由は、攻撃対象を減らすことです。
更新キーがないと仮定して、この例を見てみましょう：
建物には80のドアがあります。すべてのドアは同じ鍵で開かれます。キーは30分ごとに変更されます。30分が経過したら、古いキーをキーメーカーに渡して新しいキーを取得する必要があります。
私がハッカーで鍵を入手したら、30分が経過したら、それを鍵メーカーに宅配して新しい鍵を入手します。キーの変更に関係なく、すべてのドアを継続的に開くことができます。
質問：30分間で、キーに対してハッキングの機会がいくつありましたか？キーを使用するたびに、80回のハッキングの機会がありました（これは、ネットワークリクエストを作成し、自分を識別するためにアクセストークンを渡すと考えてください）。つまり、80Xの攻撃面です。
今度は同じ例を見てみましょうが、今回は更新キーがあると仮定しましょう。
建物には80のドアがあります。すべてのドアは同じ鍵で開かれます。キーは30分ごとに変更されます。新しいキーを取得するために、古いアクセストークンを渡すことができません。更新キーのみを渡す必要があります。
私がハッカーであなたの鍵を手に入れたら、30分間使用できますが、30分の終わりに鍵をキーメーカーに送信しても意味がありません。もしそうなら、キーメーカーはこの悪いリフレッシュトークンを言うだけです。私のハックを拡張できるようにするには、宅配業者をキーメーカーにハックする必要があります。クーリエには別個のキーがあります（これを更新トークンと考えてください）。
質問：30分間で、更新キーに対してハッキングの機会がいくつありましたか？80？いいえ。ハッキングの機会は1回しかありませんでした。その間、クーリエはキーメーカーと通信します。つまり、これは1X攻撃面です。鍵に対して80回のハッキングの機会がありましたが、30分後には良くありません。
サーバーは、資格情報と（通常）JWTの署名に基づいてアクセストークンを検証します。
アクセストークンの漏えいは悪いですが、有効期限が切れると攻撃者にとってもはや役に立ちません。更新トークンの漏えいははるかに悪いですが、おそらくその可能性は低くなります。（リフレッシュトークンのリークの可能性がアクセストークンのリークの可能性よりもはるかに低いかどうかは疑問の余地があると思いますが、それは考え方です。）
ポイントは、アクセストークンはすべてのリクエストに追加されますが、更新トークンは更新フロー中にのみ使用されるため、MITMがトークンを見る可能性が低くなります。
頻度は攻撃者を助けます。ハートブリードのような、SSLの潜在的なセキュリティ欠陥、クライアントの潜在的なセキュリティ欠陥、およびサーバーの潜在的なセキュリティ欠陥はすべてリークを可能にします。
さらに、承認サーバーが他のクライアント要求を処理するアプリケーションサーバーから分離されている場合、そのアプリケーションサーバーには更新トークンが表示されません。ずっと長く存続しないアクセストークンのみが表示されます。
区画化はセキュリティに適しています。
最後に、この素晴らしい答えを見てください
どのような更新トークンは関係ありませんか？
更新トークンを使用してアクセスレベルを更新/取り消す機能は、更新トークンを使用することを選択した場合の副産物です。それ以外の場合、スタンドアロンアクセストークンは、期限切れになり、ユーザーが新しいトークンを取得したときに、取り消されたり、アクセスレベルが変更されたりする可能性があります。
あなたがaccess_token最後のものを非常に長くして、持っていないと仮定するとrefresh_token、ある日、ハッカーはこれaccess_tokenを取得し、彼はすべての保護されたリソースにアクセスできます！
ただし、を使用しているrefresh_token場合、access_tokenのライブ時間は短いため、ハッカーはaccess_token短時間で無効になるため、ハッキングするのが難しくなります。
ハッカーが持っていないand Access_tokenだけでrefresh_tokenなく、を使用してのみ取得できます。client_idclient_secret
一方、更新トークンは認可サーバーによって保持されます。アクセストークンは自己完結型であるため、リソースサーバーは保存せずにそれを検証できます。これにより、検証の際に取得する手間が省けます。議論に欠けているもう1つのポイントは、rfc6749＃page-55からです
「たとえば、承認サーバーは、すべてのアクセストークンの更新応答で新しい更新トークンが発行される更新トークンローテーションを使用できます。以前の更新トークンは無効化されますが、承認サーバーによって保持されます。更新トークンが侵害され、その後、攻撃者と正当なクライアントの両方に、そのうちの1つが無効化された更新トークンを提示し、認証サーバーに違反を通知します。」
攻撃者がなんとかしてリフレッシュトークン、クライアントID、シークレットの組み合わせを取得できたとしても、リフレッシュトークンを使用することの要点は、後続の呼び出しで攻撃者から新しいアクセストークンを取得すると、更新のすべてのリクエストで新しいアクセストークンと更新トークンが発生した場合に追跡できます。
A Single-Page Application (normally implementing Single-Page Login Flow) should not under any circumstances get a Refresh Token. The reason for that is the sensitivity of this piece of information. You can think of it as user credentials, since a Refresh Token allows a user to remain authenticated essentially forever. Therefore you cannot have this information in a browser, it must be stored securely.
各ユーザーが1つ以上のロールにリンクされ、各ロールが1つ以上のアクセス権限にリンクされているシステムについて考えてみましょう。この情報をキャッシュして、APIのパフォーマンスを向上させることができます。ただし、ユーザーとロールの構成が変更される可能性があり（たとえば、新しいアクセスが許可されたり、現在のアクセスが取り消されたりする可能性があります）、これらはキャッシュに反映されます。
そのために、アクセストークンと更新トークンを使用できます。APIがアクセストークンを使用して呼び出されると、リソースサーバーはキャッシュにアクセス権があるかどうかを確認します。新しいアクセス許可がある場合、それはすぐには反映されません。アクセストークンの有効期限が切れ（30分など）、クライアントが更新トークンを使用して新しいアクセストークンを生成すると、DBからの更新されたユーザーアクセス権情報でキャッシュを更新できます。
つまり、アクセストークンを使用するすべてのAPI呼び出しから、更新トークンを使用するアクセストークン生成のイベントに、コストの高い操作を移動できます。
最初に、クライアントは許可付与を与えることによって許可サーバーで認証します。
次に、クライアントは、アクセストークンを与えることにより、保護されたリソースをリソースサーバーに要求します。
リソースサーバーはアクセストークンを検証し、保護されたリソースを提供します。
クライアントは、アクセストークンを付与することにより、リソースサーバーに保護されたリソース要求を作成します。リソースサーバーは、トークンを検証し、有効であれば要求を処理します。この手順は、アクセストークンの有効期限が切れるまで繰り返されます。
アクセストークンの有効期限が切れた場合、クライアントは承認サーバーで認証し、更新トークンを提供して新しいアクセストークンを要求します。アクセストークンが無効な場合、リソースサーバーはクライアントに無効なトークンエラー応答を返します。
クライアントは、更新トークンを付与することにより、承認サーバーで認証します。
次に、承認サーバーは、クライアントを認証して更新トークンを検証し、有効な場合は新しいアクセストークンを発行します。
access token + refresh token思いますか？