OAuth v2にアクセスと更新の両方のトークンがあるのはなぜですか？
ドラフトOAuth 2.0プロトコルのセクション4.2は、承認サーバがaccess_token（リソースで自分自身を認証するために使用される）と、新しいrefresh_tokenを作成するために純粋に使用されるaccess_tokenの両方を返すことができることを示しています。
https://tools.ietf.org/html/rfc6749#section-4.2
なぜ両方がありますか？ access_tokenをrefresh_tokenの長さだけ持ち続け、refresh_tokenを持たないようにするのはなぜですか。
リフレッシュトークンの考え方は、アクセストークンが短命であるために侵害された場合、攻撃者はそれを悪用するための期間が限られているということです。
攻撃者はアクセストークンを取得するためにリフレッシュトークンに加えてクライアントIDとシークレットを要求するので、妥協してもリフレッシュトークンは役に立ちません。
と言っても 、認可サーバーとリソースサーバーの両方へのすべての呼び出しはSSLを介して行われるため、元のクライアントIDとシークレットを含めてアクセス/更新トークンを要求します。アクセストークンは、長寿命のリフレッシュトークンとクライアント/シークレットの組み合わせよりも「妥協が可能」です。
これはもちろん、認可サーバーとリソースサーバーの両方を制御しない実装とは異なります。
これがリフレッシュトークンの使用法について話す良いスレッドです： OAuth Archives 。
上記からの引用、リフレッシュトークンのセキュリティ目的についての話題：
トークンの更新...長期にわたるaccess_tokenのリーク（安全でないリソースサーバーのログファイル内のクエリパラメーター、ベータ版または不十分にコーディングされたリソースサーバーアプリケーション、非httpsサイトのJS SDKクライアントがaccess_tokenを保存する）クッキーなど）
Catchdaveが提供するディスカッションへのリンクには、別の 有効なポイント（元のデッドリンク） があります。これは、Dick Hardtが作成したものです。上記の内容：
リフレッシュトークンの思い出は、セキュリティと失効のためでした。 <...>
失効：アクセストークンが自己完結型の場合、新しいアクセストークンを発行しないことで承認を取り消すことができます。リソースは、アクセストークンが有効かどうかを確認するために承認サーバーを照会する必要がありません。これにより、アクセストークンの検証が簡素化され、複数の承認サーバーのスケーリングとサポートが容易になります。アクセストークンは有効ですが、承認が取り消される場合があります。
実際、Resource ServerとAuthorization Serverが同じエンティティであり、ユーザーとそれらのいずれかの間の接続が（通常）等しく安全である状況では、更新トークンをアクセストークンから分離しておく意味はあまりありません。
ただし、引用符で述べたように、リフレッシュトークンの別の役割は、システムを同時にスケーラブルに保ちながら、ユーザーがいつでもアクセストークンを（たとえば、プロファイルのWebインターフェイスを介して）取り消せるようにすることです。
一般的に、トークンはサーバーのデータベース内の特定のレコードを指すランダムな識別子か、それ自体にすべての情報を含めることができます（確かに、この情報は MAC で署名する必要があります） ）。
長期間有効なアクセストークンを使用するシステムの動作方法
サーバーは、トークンを発行することにより、クライアントが事前定義された一連のスコープ内でユーザーのデータにアクセスできるようにします。トークンを取り消し可能にしたいので、トークンをデータベースに保存する必要があります。フラグは「失効」フラグを設定または設定解除します（そうでなければ、自己完結型トークンでどのように行いますか）。データベースにはlen(users) x len(registered clients) x len(scopes combination)記録。すべてのAPIリクエストはデータベースにヒットする必要があります。 O（1）を実行するこのようなデータベースにクエリを実行することは非常に簡単ですが、単一障害点自体がシステムのスケーラビリティとパフォーマンスに悪影響を及ぼす可能性があります。
長期間有効なリフレッシュトークンと短時間有効なアクセストークンを使用したシステムの動作方法
ここで、2つのキーを発行します。データベース内の対応するレコードを持つランダムリフレッシュトークンと、有効期限のタイムスタンプフィールドを含む署名付き自己完結型アクセストークンです。
アクセストークンは自己完結型であるため、その有効性を確認するためにデータベースにアクセスする必要はまったくありません。トークンをデコードし、署名とタイムスタンプを検証するだけです。
それでも、リフレッシュトークンのデータベースを保持する必要がありますが、このデータベースへのリクエストの数は一般にアクセストークンの寿命によって定義されます（寿命が長いほど、アクセスレートは低くなります）。
特定のユーザーからクライアントのアクセスを取り消すには、対応する更新トークンを「取り消し」としてマーク（または完全に削除）し、新しいアクセストークンの発行を停止する必要があります。ただし、更新トークンが取り消されているウィンドウが存在することは明らかですが、そのアクセストークンはまだ有効な場合があります。
トレードオフ
更新トークンは、アクセストークンデータベースのSPoF（単一障害点）を部分的に排除しますが、いくつかの明らかな欠点があります。
窓"。 「ユーザーがアクセスを取り消す」イベントと「アクセスが取り消されることが保証されている」イベントの間の時間枠。
クライアントロジックの複雑さ。
withoutリフレッシュトークン
- アクセストークンでAPIリクエストを送信する
- アクセストークンが無効な場合、失敗し、ユーザーに再認証を要求します
withリフレッシュトークン
- アクセストークンでAPIリクエストを送信する
- アクセストークンが無効な場合は、更新トークンを使用して更新してみてください
- 更新リクエストが成功した場合、アクセストークンを更新し、最初のAPIリクエストを再送信します
- 更新要求が失敗した場合は、ユーザーに再認証を依頼してください
この答えが理にかなっており、誰かがより思慮深い決定を下すのに役立つことを願っています。また、githubやfoursquareなどの有名なOAuth2プロバイダーは、リフレッシュトークンを使用せずにプロトコルを採用しており、これに満足しているようです。
上記のすばらしい答えにもかかわらず、私は以前にeBayでバイヤーの保護と詐欺を調べたときにセキュリティマスターの学生およびプログラマーとして、アクセストークンとリフレッシュトークンを分離すると言うことができますベストバランス = frequentユーザー名/パスワード入力のユーザーへの嫌がらせと、潜在的なアクセス権を取り消す権限を手元に保持するabuseサービスの。
このようなシナリオを考えてください。ユーザーに3600秒のアクセストークンを発行し、トークンを1日よりもはるかに長く更新します。
ユーザーはgoodユーザーであり、自宅にいて、あなたのウェブサイトで買い物をしたり、iPhoneで検索したりします。彼のIPアドレスは変更されず、サーバーの負荷は非常に低くなります。毎分3〜5ページのリクエストのように。アクセストークンの3600秒が終わると、彼はリフレッシュトークンを持つ新しいトークンを要求します。サーバー側で、私たちは彼の活動履歴とIPアドレスを確認し、彼は人間であり、自分自身で行動していると考えています。サービスを引き続き使用するために、新しいアクセストークンを付与します。ユーザーは、更新トークン自体の1日の寿命に達するまで、ユーザー名/パスワードを再度入力する必要はありません。
ユーザーはcarelessユーザーです。彼はニューヨーク、アメリカ合衆国に住んでおり、ウイルスプログラムをシャットダウンし、ポーランドのハッカーにハッキングされました。ハッカーはアクセストークンとリフレッシュトークンを取得すると、ユーザーになりすましてサービスを使用しようとします。しかし、短命のアクセストークンの有効期限が切れた後、ハッカーがアクセストークンを更新しようとすると、サーバー上でユーザーの行動履歴の劇的なIPの変更に気付きました（この男はアメリカにログインし、今ポーランドでアクセスを更新しますわずか3600秒後???）。更新プロセスを終了し、更新トークン自体を無効にして、ユーザー名/パスワードの再入力を求めます。
ユーザーはmaliciousユーザーです。彼は、ロボットを使用して毎分1000回APIを呼び出すことにより、サービスを悪用することを意図しています。彼は3600秒後にアクセストークンを更新しようとするまでうまくやることができます。更新プロセスを拒否して終了し、ユーザー名/パスワードの再入力を求めます。これにより、ロボットの自動フローが中断される可能性があります。少なくとも彼を不快にします。
作業、ユーザーエクスペリエンス、および盗まれたトークンの潜在的なリスクのバランスをとろうとすると、更新トークンが完全に機能したことがわかります。サーバー側のウォッチドッグは、IPの変更やAPI呼び出しの頻度以外にも、ユーザーが良いユーザーであるかどうかを判断できます。
別の言葉では、各API呼び出しで基本的なIPウォッチドッグまたはその他の手段を実装することにより、盗まれたトークン/サービスの不正使用のダメージ制御を制限することもできます。ただし、ユーザーに関するレコードを読み書きする必要があり、サーバーの応答が遅くなるため、これは高価です。
どちらの答えも、リフレッシュトークンが存在する根本的な理由には到達しません。クライアントの認証情報を認証サーバーに送信することで、いつでも新しいアクセストークンと更新トークンのペアを取得できます。つまり、最初に取得する方法です。
したがって、更新トークンの唯一の目的は、認証サービスにネットワーク経由で送信されるクライアント資格情報の使用を制限することです。アクセストークンのttlが短いほど、新しいアクセストークンを取得するためにクライアントの資格情報を使用する必要が多くなるため、攻撃者がクライアントの資格情報を危険にさらす機会が増えます（ただしそれらを送信するために非対称暗号化が使用されています。したがって、使い捨てのリフレッシュトークンがある場合は、クライアントの資格情報を損なうことなく、アクセストークンの総数を任意に小さくすることができます。
混乱を解消するには、クライアントシークレットと ユーザーパスワード の役割を理解する必要があります。これらはまったく異なります。
client は、サードパーティの認証を使用して 認証 a user にしたい、サーバーに支えられたapp/website/program/...です。サービス。クライアントシークレットは、このクライアントと認証サーバーの両方に知られている（ランダムな）文字列です。この秘密を使用して、クライアントは認証サーバで自分自身を識別し、 authorization を受け取ってアクセストークンを要求できます。
初期アクセストークンと更新トークンを取得するには、次のものが必要です。
- ユーザーID
- ユーザーパスワード
- クライアントID
- クライアントの秘密
しかし、更新されたアクセストークンを取得するために、 client は次の情報を使用します。
- クライアントID
- クライアントの秘密
- 更新トークン
これは違いを明確に示しています。更新時に、クライアントはクライアントシークレットを使用してアクセストークンを更新するための承認を受けているため、更新トークン 代わりに ユーザーID +パスワードを使用してユーザーを再認証できます。これにより、ユーザーが自分のパスワードを再入力する必要がなくなります。
これはまた、クライアントIDとシークレットがわからないため、更新トークンを失っても問題ないことを示しています。また、クライアントIDとクライアントシークレットを秘密にすることが vital であることも示しています。
この回答は、OAuth 2標準のボディメーリングリストを介してJustin Richerからのものです。これは彼の許可を得て投稿されています。
更新トークンの有効期間は、（AS）許可サーバーまでです。期限切れや取り消しなどが可能です。更新トークンとアクセストークンの違いはオーディエンスです。アクセストークンは（RS）リソースサーバーに行きます。
また、アクセストークンを取得しただけでは、ユーザーがログインしているということにはなりません。アクセストークンを更新しても、ユーザーに代わってAPIにアクセスすることはできますが、ユーザーがいるかどうかはわかりません。
OpenID Connectは、アクセストークンからユーザー情報を提供するだけではなく、IDトークンも提供します。これは、ASやRSではなく、クライアント自体に向けられた個別のデータです。 OIDCでは、新しいIDトークンを取得できるのであれば、誰かが実際にプロトコルによって「ログイン」していると考えるべきです。リフレッシュするだけでは不十分です。
クライアントはさまざまな方法で侵害される可能性があります。例えば、携帯電話を複製することができます。アクセストークンの有効期限が切れると、クライアントは認証サーバーに対して再認証を余儀なくされます。再認証中に、認証サーバは他の特性をチェックできます（IOWはアダプティブアクセス管理を実行します）。
更新トークンはクライアントに再認証のみを許可します。ここで、re-authorizeがユーザーとの対話を強制し、多くのユーザーはそうしたくないと示唆しています。
リフレッシュトークンは、通常のWebサイトが1時間程度経過した後に定期的にユーザーを再認証することを選択する場合がある場所と本質的に同じ場所に収まります（例：銀行のサイト）。ほとんどのソーシャルWebサイトはWebユーザーを再認証しないため、現在はあまり使用されていません。では、なぜクライアントを再認証するのでしょうか。
B Tの答えをさらに単純化するには：ユーザーに通常は資格情報を再度入力させる必要はないが、（更新トークンを取り消して）権限を取り消すことができるようにしたい場合は、更新トークンを使用します。
アクセストークンを取り消すことはできません。更新トークンだけを取り消すことができます。
Access_tokenをrefresh_tokenと同じ長さだけ保持し、refresh_tokenを持たないようにするのはなぜですか。
素晴らしい回答に加えて、他の人が提供している別の理由として、リフレッシュトークンを使用する理由とクレームを処理する理由があります。
各トークンには、ユーザー名、その役割、または要求を作成したプロバイダーからのものをすべて含めることができる要求が含まれています。トークンが更新されると、これらの要求は更新されます。
トークンをより頻繁に更新すると、明らかにアイデンティティサービスにより多くの負担がかかりますが、より正確で最新のクレームが得られます。
Access_tokenを非常に長くし、refresh_tokenを持たないと仮定します。そのため、ある日、ハッカーがこのaccess_tokenを取得すれば、保護されたすべてのリソースにアクセスできます。
しかし、あなたがrefresh_tokenを持っているなら、access_tokenのライブタイムは短いです、それでハッカーはあなたのaccess_tokenを短期間の後に無効になるのでハッキングするのは難しいです。 Access_tokenはrefresh_tokenだけでなく、client_idとclient_secretによっても取り戻すことができます。
リフレッシュトークンは認可サーバーによって保持されます。アクセストークンは自己完結型であるため、リソースサーバはそれを格納することなくそれを検証することができ、検証の際に検索の手間を省くことができます。議論に欠けているもう一つの点はrfc6749からです＃55ページ
「たとえば、承認サーバーは、更新トークンローテーションを使用して、アクセストークンの更新応答ごとに新しい更新トークンを発行することができます。以前の更新トークンは無効になりますが、承認サーバーによって保持されます。攻撃者でも正当なクライアントでも、どちらか一方が無効化された更新トークンを提示し、それが認可サーバーに違反を知らせます。」
リフレッシュトークンを使用することの全体的なポイントは、たとえ攻撃者がリフレッシュトークン、クライアントID、およびシークレットの組み合わせを何らかの形で取得したとしてもだと思います。更新を要求するたびに新しいアクセストークンと更新トークンが返された場合に備えて、攻撃者から新しいアクセストークンを取得する後続の呼び出しを追跡できます。
この答えは、2人の上級開発者（John BraytonとDavid Jennes）の助けによってまとめられました。
更新トークンを使用する主な理由は、攻撃対象領域を減らすことです。
更新キーがないと仮定して、この例を見てみましょう。
建物には80個のドアがあります。すべてのドアは同じキーで開きます。キーは30分ごとに変更されます。
私がハッカーでキーを入手したら、30分の終わりにそれをキーメーカーに宅配して新しいキーを入手します。キーの変更に関係なく、すべてのドアを継続的に開くことができます。
質問：30分間に、キーに対して何回ハッキングの機会がありましたか？キーを使用するたびに、80回のハッキングの機会がありました（これは、ネットワーク要求を作成し、アクセストークンを渡して自分を識別すると考えてください）。つまり、80倍の攻撃対象領域です。
同じ例を見てみましょうが、今回は更新キーがあると仮定します。
建物には80個のドアがあります。すべてのドアは同じキーで開きます。キーは30分ごとに変更されます。私がハッカーであり、あなたの鍵を手に入れれば、私はそれを30分間使用できますが、30分の終わりにそれをキーメーカーに送信しても価値はありません。もしそうなら、キーメーカーはこのキーが期限切れだと言うでしょう。ハックを拡張するには、宅配便業者をキーメーカーにハッキングする必要があります。クーリエには個別のキーがあります（これをリフレッシュトークンと考えてください）。
質問：30分間に、宅配便に対して何回ハッキングする機会がありましたか？ 80？いいえ。ハッキングの機会は1回だけでした。その間、宅配便業者はキーメーカーと通信します。これが1倍の攻撃対象領域です。キーに対して80回のハッキングの機会がありましたが、30分後にはうまくいきません。
サーバーは、資格情報と（通常）JWTの署名に基づいてアクセストークンを検証します。
アクセストークンの漏洩は不良ですが、有効期限が切れると、攻撃者にとっては役に立ちません。リフレッシュトークンのリークははるかに悪いですが、おそらくそうではないでしょう。 （リフレッシュトークンのリークの可能性がアクセストークンのリークの可能性よりもはるかに低いかどうかは疑問の余地があると思いますが、それはアイデアです。）
ポイントは、アクセストークンが作成するすべてのリクエストに追加されるのに対し、リフレッシュトークンはリフレッシュフロー中にのみ使用されるため、MITMがトークンを参照する可能性が低くなることです。
頻度は攻撃者を助けます。 Heartbleed -SSLの潜在的なセキュリティの欠陥、クライアントの潜在的なセキュリティの欠陥、およびサーバーの潜在的なセキュリティの欠陥はすべて、漏洩を可能にします。
さらに、承認サーバーが他のクライアント要求を処理するアプリケーションサーバーとは別の場合、そのアプリケーションサーバーは更新トークンを参照しません。ずっと長く存続しないアクセストークンのみが表示されます。
区画化はセキュリティに適しています。
リフレッシュトークンとは何ですか？
リフレッシュトークンを使用してアクセスレベルを更新/取り消す機能は、リフレッシュトークンを使用することを選択した副産物です。
最初に、クライアントは許可付与を与えることによって許可サーバーと認証します。
次に、クライアントはアクセストークンを渡して、保護されたリソースをリソースサーバーに要求します。
リソースサーバーはアクセストークンを検証し、保護されたリソースを提供します。
クライアントは、アクセストークンを許可することによって保護されたリソース要求をリソースサーバーに送信します。アクセストークンはリソーストークンを検証し、有効な場合は要求を処理します。この手順は、アクセストークンが期限切れになるまで繰り返されます。
アクセストークンの有効期限が切れると、クライアントは認証サーバーで認証し、更新トークンを提供して新しいアクセストークンを要求します。アクセストークンが無効な場合、リソースサーバーは無効なトークンエラー応答をクライアントに返信します。
クライアントは、更新トークンを許可することによって許可サーバーと認証します。
その後、認証サーバーはクライアントを認証することによって更新トークンを検証し、有効な場合は新しいアクセストークンを発行します。
各ユーザーが1つ以上のロールにリンクされ、各ロールが1つ以上のアクセス権限にリンクされているシステムを考えてみましょう。この情報は、より良いAPIパフォーマンスのためにキャッシュすることができます。しかし、その場合、ユーザーおよびロールの設定に変更があり（たとえば、新しいアクセスが許可されたり、現在のアクセスが取り消されたりするなど）、これらがキャッシュに反映されるはずです。
このような目的のためにアクセストークンとリフレッシュトークンを使用できます。 APIがアクセストークンで呼び出されると、リソースサーバーはキャッシュでアクセス権を確認します。新しいアクセス許可がある場合は、すぐには反映されません。アクセストークンが期限切れになり（30分以内に）、クライアントが更新トークンを使用して新しいアクセストークンを生成すると、キャッシュはDBからの更新されたユーザーアクセス権情報で更新されます。
つまり、アクセストークンを使用したすべてのAPI呼び出しから、リフレッシュトークンを使用したアクセストークン生成のイベントに、コストのかかる操作を移すことができます。