YouTube Live StreamingAPIと統合するプログラムがあります。タイマーで実行されるため、更新トークンを使用して50分ごとに新しいアクセストークンをフェッチするようにプログラムするのは比較的簡単でした。私の質問は、なぜですか？
YouTubeで認証すると、更新トークンが提供されました。次に、この更新トークンを使用して、約1時間に1回新しいアクセストークンを取得します。更新トークンを持っている場合、有効期限が切れることはないため、常にこれを使用して新しいアクセストークンを取得できます。したがって、最初からアクセストークンを提供し、リフレッシュトークンシステム全体を気にしないこと以上に、これがどのように安全であるかはわかりません。
回答:
基本的に、更新トークンは新しいアクセストークンを取得するために使用されます。
これら2つのトークンを明確に区別し、混同を避けるために、OAuth2.0認証フレームワークで提供される機能は次のとおりです。
- アクセストークンは、リソース所有者の承認を得て、承認サーバーによってサードパーティクライアントに発行されます。クライアントはアクセストークンを使用して、リソースサーバーによってホストされている保護されたリソースにアクセスします。
- 更新トークンは、アクセストークンを取得するために使用される資格情報です。更新トークンは、認証サーバーによってクライアントに発行され、現在のアクセストークンが無効になるか期限切れになったときに新しいアクセストークンを取得するため、または同一またはより狭い範囲の追加のアクセストークンを取得するために使用されます。
ここで、アクセストークンを保護するだけでなく、なぜまだ更新トークンが発行されているのかという質問に答えるために、インターネット技術特別調査委員会が更新トークンで提供する主な理由は次のとおりです。
セキュリティ上の理由があります。
refresh_tokenこれは認証サーバーとのみ交換されますが、access_tokenはリソースサーバーと交換されます。これにより、「1時間有効なアクセストークン、1年間有効な更新トークン、または取り消されるまで有効なアクセストークン」と、「更新なしで完全に取り消されたアクセストークン」で、長期間有効なaccess_tokenがリークするリスクが軽減されます。トークン。"
OAuth 2.0フローの詳細で完全な情報については、次のリファレンスを参照してください。
@TeyamがSOの投稿に言及しているOAuthv2にアクセストークンと更新トークンの両方があるのはなぜですか？しかし、私はそこに別の答えを好みます：https：//stackoverflow.com/a/12885823/254109
TL; DR refresh_tokenはセキュリティの向上をもたらしません。これは、スケーラビリティとパフォーマンスを向上させることを目的としています。次に、access_token高速の一時ストレージ（メモリなど）に保存することができます。承認とリソースサーバーの分離も可能です。
更新トークンには、少なくとも2つの目的があります。まず、更新トークンは、OAuth2クライアントがユーザーからデータへのアクセス許可をすでに受け取っていることの一種の「証明」であるため、ユーザーがOAuth2フロー全体を実行しなくても、新しいアクセストークンを再度要求できます。そして第二に、それは長命のアクセストークンと比較してセキュリティの全体の流れを増やすのに役立ちます。これらの両方の点についてもう少し詳しく触れます。
最初の目的について例を挙げて話しましょう。ユーザーであるあなたが、YouTubeアカウントデータを操作したいサードパーティのクライアントWebアプリケーションを使用していたとします。クライアントアプリケーションにYouTubeデータの使用を許可したら、クライアントアプリから再度許可を求めるプロンプトを表示しますか？YouTubeトークンの有効期限が切れたのはいつですか？YouTubeトークンの有効期限が5分など、非常に短い場合はどうなりますか。クライアントアプリケーションが少なくとも5分ごとに許可を求めるプロンプトを表示するのは、少し面倒です。OAuth2がこの「問題」に対して提案する解決策は、更新トークンです。更新トークンを使用することで、アクセストークンの有効期間を短くすることができ（アクセストークンがリークされたり、何らかの理由で盗まれた場合に望ましい）、更新トークンの有効期間を長くすることができるため、クライアントは新しいアクセスを取得できます。ユーザーの許可を必要とせずに（再び）期限切れになったときのトークン。
しかし、なぜリフレッシュトークンなのですか？ポイントがアクセス許可要求でユーザーを悩ませないことである場合、なぜクライアントは単に「ねえ、認証サーバー、別のアクセストークンが必要です。今すぐ！」と言うことができないのですか？または、「Hey Authorization Server、これが期限切れのトークンです。新しいトークンをください！」さて、更新トークンは、ある元の時点でクライアントがユーザーによってアクセスを許可されたという一種の「証拠」として機能します。この「証明」は、認証サーバーによってデジタル署名された更新トークンの形式です。クライアントが更新トークンを提示することにより、承認サーバーは、クライアントが過去のある時点でユーザーから許可を受け取ったことを確認でき、クライアントはユーザーに再度プロンプトを表示する必要がありません。
ただし、これにより、「更新トークンがリークまたは盗まれた場合、またはユーザーの要求に応じて更新トークンを削除しない悪意のあるクライアントアプリケーションによって保持された場合はどうなりますか？攻撃者は続行できません。更新トークンを使用して、有効なアクセストークンを無期限に（または有効期限が切れるまで）取得しますか？この質問は、より安全なフローに寄与する更新トークンの2番目の目的について説明します。
アクセストークンで発生する問題は、一度取得すると、リソースサーバー（YouTubeなど）にのみ提示されることです。では、アクセストークンが盗まれたり侵害されたりした場合、そのトークンを信頼しないようにResource Serverにどのように指示しますか？まあ、あなたは本当にできません。これを行う唯一の方法は、認証サーバーの秘密署名キー（最初にトークンに署名したキー）を変更することです。これは不便であり、場合によっては（Auth0など）サポートされていないと思います。
一方、更新トークンは承認サーバーに頻繁に提示する必要があるため、1つが侵害された場合は、更新トークン全体を取り消すか拒否するのは簡単で、署名キーを変更する必要はありません。
「したがって、最初からアクセストークンを提供し、Refresh Tokenシステム全体に煩わされることなく、これがどのように安全であるかはわかりません。」私は同じ質問に苦労しました。簡単に言うと、資格情報の有効期限が切れていないことを確認するには、更新トークンが必要です。
例が役立つかもしれません：私はあなたの医療記録を保存するデータベースを持っています。あなたはあなたの医療記録をあなたの配偶者と共有することに同意します。あなたの配偶者は彼らのアクセストークンを使用して私のデータベースからあなたの記録を読み取ります。今から2週間後、あなたの配偶者はあなたの医療記録を再度チェックし、更新トークンを使用して、あなたの記録を表示するための（認証サーバーからの）許可がまだあることを確認します。更新トークンは、配偶者が認証サーバーに資格情報（ユーザー名とパスワード）を再入力する必要性を回避しますが、リソースにアクセスするための正当性を維持します。有効期限が切れないアクセストークンは、あなたがあなたの医療記録にアクセスするためのあなたの配偶者の権利を取り消したかどうかを知りません。