ドラフトOAuth2.0プロトコルのセクション4.2は、承認サーバーがaccess_token（リソースで自分自身を認証するために使用される）と、refresh_token純粋に新しいものを作成するために使用される、の両方を返すことができることを示していaccess_tokenます。
https://www.rfc-editor.org/rfc/rfc6749#section-4.2
なぜ両方を持っているのですか？を持っていないaccess_token限り、最後を作ってみませんか？refresh_tokenrefresh_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 プロバイダーの中には、リフレッシュ トークンのないプロトコルを採用しているものもあり、それに満足しているように見えることにも注意してください。
リフレッシュ トークンの考え方は、アクセス トークンが侵害された場合、有効期間が短いため、攻撃者がそれを悪用できる期間が限られているというものです。
攻撃者はアクセス トークンを取得するために、更新トークンに加えてクライアント ID とシークレットを必要とするため、侵害された場合、更新トークンは役に立ちません。
そうは言っても、認可サーバーとリソース サーバーの両方へのすべての呼び出しは SSL 経由で行われるため、アクセス/リフレッシュ トークンを要求する際の元のクライアント ID とシークレットを含めて、アクセス トークンがどのようになっているのかわかりません」長期間有効な更新トークンと clientid/secret の組み合わせよりも危険です。
これはもちろん、認可サーバーとリソース サーバーの両方を制御しない実装とは異なります。
これは、更新トークンの使用について話している良いスレッドです: OAuth Archives。
リフレッシュトークンのセキュリティ目的について話している上記からの引用：
トークンの更新... 長期にわたる access_token のリークのリスクを軽減します (安全でないリソース サーバー上のログ ファイル内のクエリ パラメータ、ベータ版または適切にコーディングされていないリソース サーバー アプリ、access_token をクッキーなど）
上記のすべての素晴らしい回答にもかかわらず、以前 eBay でバイヤー プロテクションと詐欺を調べたときに働いていたセキュリティ マスターの学生およびプログラマーとして、アクセス トークンとリフレッシュ トークンを分離することが、ユーザー名を頻繁に使用するユーザーへの嫌がらせとの間で最良のバランスを取っていると言えます。 /password を入力し、権限を保持して、サービスの潜在的な悪用へのアクセスを無効にします。
このようなシナリオを考えてください。3600 秒のアクセス トークンのユーザーを発行し、トークンを更新するのは 1 日とはるかに長くなります。
このユーザーは優れたユーザーであり、自宅にいて、Web サイトでのショッピングや iPhone での検索を行ったり来たりしています。彼の IP アドレスは変更されず、サーバーの負荷は非常に低くなります。毎分 3 ～ 5 ページのリクエストのように。アクセス トークンの 3600 秒が経過すると、更新トークンを含む新しいトークンが必要になります。サーバー側では、彼の行動履歴とIPアドレスを確認し、彼が人間であると考えて行動します。サービスを継続して使用するための新しいアクセス トークンを彼に付与します。ユーザーは、リフレッシュ トークン自体の有効期間が 1 日経過するまで、ユーザー名とパスワードを再度入力する必要はありません。
ユーザーは不注意なユーザーです。彼はアメリカのニューヨークに住んでいて、ウイルス プログラムをシャットダウンし、ポーランドでハッカーにハッキングされました。ハッカーはアクセス トークンとリフレッシュ トークンを取得すると、ユーザーになりすましてサービスを利用しようとします。しかし、短期間のアクセス トークンの有効期限が切れた後、ハッカーがアクセス トークンを更新しようとすると、サーバー上で、ユーザーの行動履歴に劇的な IP の変化があることに気付きました (この男は米国でログインし、現在はポーランドでアクセスを更新しています)ちょうど3600秒後???)。更新プロセスを終了し、更新トークン自体を無効にして、ユーザー名とパスワードを再度入力するように求めます。
ユーザーが悪意のあるユーザーです。彼は、ロボットを使用して毎分 1000 回 API を呼び出すことで、サービスを悪用することを意図しています。彼は 3600 秒後までそうすることができ、アクセス トークンを更新しようとすると、私たちは彼の行動に気づき、彼が人間ではない可能性があると考えました。更新プロセスを拒否して終了し、ユーザー名とパスワードを再度入力するように依頼します。これにより、ロボットの自動フローが中断される可能性があります。少なくとも彼を不快にさせます。
作業、ユーザー エクスペリエンス、およびトークンが盗まれる潜在的なリスクのバランスを取ろうとすると、リフレッシュ トークンが完璧に機能したことがわかります。サーバー側の番犬は、IP の変更や API 呼び出しの頻度だけでなく、ユーザーが適切なユーザーであるかどうかを判断できます。
別の言い方をすれば、各 API 呼び出しに基本的な IP ウォッチドッグまたはその他の手段を実装することで、盗まれたトークン/サービスの悪用による被害の抑制を試みることもできます。ただし、ユーザーに関するレコードを読み書きする必要があり、サーバーの応答が遅くなるため、これにはコストがかかります。
これらの答えはどちらも、リフレッシュ トークンが存在する主な理由にはなりません。明らかに、クライアント資格情報を認証サーバーに送信することで、いつでも新しいアクセス トークン/リフレッシュ トークンのペアを取得できます。これが、最初にそれらを取得する方法です。
したがって、更新トークンの唯一の目的は、ネットワーク経由で認証サービスに送信されるクライアント資格情報の使用を制限することです。アクセス トークンのTTLが短いほど、新しいアクセス トークンを取得するためにクライアントの資格情報を使用しなければならない頻度が高くなるため、攻撃者がクライアントの資格情報を侵害する機会が増えます (ただし、それらを送信するために非対称暗号化が使用されています）。したがって、使い捨てのリフレッシュ トークンがある場合は、クライアントの資格情報を損なうことなく、アクセス トークンの TTL を任意に小さくすることができます。
いくつかの混乱を解消するには、クライアント シークレットとユーザー パスワードの役割を理解する必要があります。これらは大きく異なります。
クライアントは、サードパーティの認証サービスを使用してユーザーを認証したい、サーバーに支えられたアプリ/ウェブサイト/プログラム/... です。クライアント シークレットは、このクライアントと認証サーバーの両方に知られている (ランダムな) 文字列です。このシークレットを使用して、クライアントは認証サーバーで自分自身を識別し、アクセス トークンを要求する承認を受け取ることができます。
初期アクセス トークンとリフレッシュ トークンを取得するには、次のものが必要です。
更新されたアクセス トークンを取得するために、クライアントは次の情報を使用します。
これは明らかに違いを示しています。更新時に、クライアントはクライアント シークレットを使用してアクセス トークンを更新する承認を受け取り、ユーザー ID とパスワードの代わりに更新トークンを使用してユーザーを再認証できます。これにより、ユーザーがパスワードを再入力する必要がなくなります。
これは、クライアント ID とシークレットがわからないため、更新トークンを失っても問題がないことも示しています。また、クライアント ID とクライアント シークレットを秘密にしておくことが重要であることも示しています。
この回答は、OAuth 2 標準ボディのメーリング リストを介した Justin Richer からのものです。本人の許可を得て掲載しています。
リフレッシュ トークンの有効期間は、(AS) 承認サーバー次第です。期限が切れたり、取り消されたりする可能性があります。リフレッシュ トークンとアクセス トークンの違いは対象者です。リフレッシュ トークンは承認サーバーにのみ返されます。アクセス トークンは (RS) リソース サーバーに送られます。
また、アクセス トークンを取得しただけでは、ユーザーがログインしたことにはなりません。実際、ユーザーはもうそこにいない可能性もあります。実際には、これがリフレッシュ トークンの意図した使用例です。アクセス トークンを更新すると、ユーザーに代わって API にアクセスできるようになります。ユーザーがそこにいるかどうかはわかりません。
OpenID Connect は、アクセス トークンからユーザー情報を提供するだけでなく、ID トークンも提供します。これは、AS や RS ではなく、クライアント自体に向けられた個別のデータです。OIDC では、新しい ID トークンを取得できる場合にのみ、プロトコルによって実際に「ログイン」した人を考慮する必要があります。リフレッシュするだけでは十分ではない可能性があります。
クライアントはさまざまな方法で危険にさらされる可能性があります。たとえば、携帯電話のクローンを作成できます。アクセス トークンの有効期限が切れるということは、クライアントが認可サーバーに対して強制的に再認証されることを意味します。再認証中に、認可サーバーは他の特性をチェックできます (IOW は適応型アクセス管理を実行します)。
リフレッシュ トークンはクライアントのみの再認証を可能にしますが、再認証はユーザーとの対話を強制しますが、多くの人はそうしたくないと述べています。
リフレッシュ トークンは、基本的に、通常の Web サイトが 1 時間ほど後に定期的にユーザーを再認証することを選択するのと同じ場所 (銀行サイトなど) に適合します。現在、ほとんどのソーシャル Web サイトは Web ユーザーを再認証しないため、あまり使用されていません。では、なぜクライアントを再認証するのでしょうか?
access_token を refresh_token と同じくらい持続させ、refresh_token を持たないようにしないのはなぜですか?
他の人が提供したすばらしい回答に加えて、リフレッシュ トークンを使用する理由がもう 1 つあります。それはクレームに関係しています。
各トークンには、ユーザーの名前、ロール、またはクレームを作成したプロバイダーから何でも含めることができるクレームが含まれています。トークンが更新されると、これらのクレームが更新されます。
トークンをより頻繁に更新すると、ID サービスにより多くの負担がかかることは明らかです。ただし、より正確で最新の主張を得ています。
リフレッシュ トークンは認可サーバーによって保持されます。アクセストークンは自己完結型であるため、リソースサーバーはそれを保存せずに検証できるため、検証の場合に取得の労力を節約できます。議論に欠けている別の点は、rfc6749#page-55 からのものです。
「たとえば、認可サーバーは、アクセストークンのリフレッシュ応答ごとに新しいリフレッシュトークンが発行されるリフレッシュトークンローテーションを採用できます。以前のリフレッシュトークンは無効になりますが、認可サーバーによって保持されます。リフレッシュトークンが侵害され、その後によって使用される場合攻撃者と正当なクライアントのいずれかが、無効化された更新トークンを提示し、認証サーバーに違反を通知します。」
更新トークンを使用することの要点は、攻撃者が何らかの方法で更新トークン、クライアント ID、およびシークレットの組み合わせを取得できたとしても、それだと思います。攻撃者から新しいアクセス トークンを取得するための後続の呼び出しで、更新のすべての要求が新しいアクセス トークンと更新トークンをもたらす場合に追跡できます。
リフレッシュトークンとアクセストークンは単なる用語です。
このちょっとした類推は、アクセス トークンとリフレッシュ トークンを使用する背後にある理論的根拠を固めるのに役立ちます。
アリスが郵便でボブに小切手を送ったとします。この小切手は、発行から 1 時間以内 (仮想) に現金化できます。しかし、アリスは銀行宛ての投稿にメモも含め、小切手が少し遅れた場合に備えて小切手を受け入れて現金化するよう銀行に依頼しました（規定の範囲内）。
ボブがこの小切手を受け取ったとき、この小切手が改ざんされていること (トークンの改ざん) を見つけた場合、ボブは自分でこの小切手を破棄します。そうでない場合は、銀行に持って行って現金化することができます。ここで、銀行は、発行時間が 1 時間の制限時間を超えたことに気付いたが、許容範囲内で規定された遅延が発生した場合に銀行に現金化するよう求めるアリスからの署名入りのメモを見た場合。
銀行はこのメモを見て、署名されたメッセージの検証を試み、アリスがまだ適切な権限を持っているかどうかを確認します。はいの場合、銀行は小切手を現金化します。Bob はこれを Alice に確認できるようになりました。
それほど正確ではありませんが、このアナロジーは、トランザクションの処理に関連するさまざまな部分に気付くのに役立ちます。
主に、スケーラビリティを最適化するために、認証サーバーへの API 呼び出しの数を減らし、最終的にはデータベースへの API 呼び出しの数を減らしたいと考えています。そして、利便性と安全性の適切なバランスでこれを行う必要があります。
注: 確かに、認証サーバーがチェーン内のリソース サーバーよりも先にリクエストに応答することがより一般的です。
私が理解していることから、リフレッシュ トークンは、アクセスを取り消す必要がある場合にパフォーマンスとコストを節約するためだけに存在します。
例 1: リフレッシュ トークンを実装しないでください。有効期間の長いアクセス トークンのみを実装します。ユーザーがサービスを悪用している場合 (例: サブスクリプションを支払っていない場合)、アクセス トークンを取り消すことができる必要があります => API 呼び出しごとにアクセス トークンの有効性を確認する必要があります。アクセス トークンが必要であり、これは DB ルックアップが必要なため遅くなります (キャッシュが役立ちますが、それはより複雑になります)。
例 2: 更新トークンと有効期間の短いアクセス トークンを実装します。ユーザーがサービスを悪用している場合 (例: サブスクリプションを支払っていない場合)、アクセス トークンを取り消すことができる必要があります白 (例: 1 時間) であり、ユーザーは新しいアクセス トークンを取得する必要があるため、アクセス トークンを必要とするすべての API 呼び出しで検証を行う必要はありません。リフレッシュ トークンからアクセス トークンを生成するときに、ユーザーを検証するだけで済みます。悪意のあるユーザーの場合、アクセス トークンを生成できない場合は、ユーザーをログアウトできます。ユーザーが再度ログインしようとすると、検証が再度実行され、エラーが返されます。
まず、クライアントは認可グラントを与えることで認可サーバーで認証を行います。
次に、クライアントは、アクセス トークンを与えることによって、保護されたリソースのリソース サーバーを要求します。
リソース サーバーはアクセス トークンを検証し、保護されたリソースを提供します。
クライアントは、アクセス トークンを付与することによって、保護されたリソース リクエストをリソース サーバーに送信します。リソース サーバーはトークンを検証し、有効な場合はリクエストを処理します。この手順は、アクセス トークンの有効期限が切れるまで繰り返されます。
アクセス トークンの有効期限が切れると、クライアントは承認サーバーで認証し、更新トークンを提供して新しいアクセス トークンを要求します。アクセス トークンが無効な場合、リソース サーバーは無効なトークンのエラー応答をクライアントに返します。
クライアントは、リフレッシュ トークンを付与することにより、認可サーバーで認証を行います。
次に、認可サーバーは、クライアントを認証することによって更新トークンを検証し、有効な場合は新しいアクセス トークンを発行します。
リフレッシュ トークンとアクセス トークンは多くのセマンティクスを含む用語であるため、用語の変更が役立つでしょうか?
2020 年には、更新トークンがブラウザーにも存在できることが認められるようになりました (当初はバックエンド システム用に提供されていました) - https://pragmaticwebsecurity.com/articles/oauthoidc/refresh-token-protection-implicationsを参照してください。このため、焦点は「更新可能性」(ユーザーが不在の場合にバックエンドが API へのアクセスをどのように延長するか) から「取り消し可能性」に切り替えられました。
したがって、リフレッシュ トークンを取り消し可能なトークンとして読み取り、アクセス トークンを取り消し不可能なトークン(おそらくFast Expiring Non Revokable Tokens ) として読み取る方が安全に見えます。
2021 年のグッド プラクティスに関する補足として、システムは常に取り消し可能なトークンから開始し、承認サーバーへのプレッシャーが高まると、取り消し不可能なトークンに移行できます。