テストの目的で更新トークンを短期間に数回使用しましたが、Google更新トークンが期限切れになるかどうか疑問に思いますか？同じ更新トークンを使用して、別のアクセストークンを長期間（1週間または数か月）何度も取得できますか？
回答:
Google Authサーバーが発行した更新トークンが期限切れになることはありません。これが更新トークンの要点です。ユーザーがアプリケーションへのアクセスを取り消すと、更新トークンの有効期限が切れます（または、無許可になるはずです）。
このドキュメントを参照してください。更新トークンの機能が明確に記載されています。
長期的なトークンを発行する代わりに（通常は1年または無制限のライフタイムで有効）、サーバーは短期間のアクセストークンと長期の更新トークンを発行できます。つまり、アクセスを承認したユーザーがアプリケーションへのアクセスを取り消すまで、簡単にリフレッシュトークンを使用できます。
これは非常に混乱するスレッドです。最初の答えは正しいように見えますが、実際にはグーグルからの信頼できるものを引用していません。
私が見つけた最も決定的な答えは、実際にはトークンを取得する開発者の遊び場です。ステップ2の下部には、次のように記載されています。
「注：OAuth Playgroundは更新トークンを保存しませんが、更新トークンは期限切れにならないため、手動で取り消す場合は、ユーザーはGoogleアカウントの承認済みアクセスページにアクセスする必要があります。」
私はそれが完全に本当だとは思いません：
発行される更新トークンの数には制限があることに注意してください。クライアントとユーザーの組み合わせごとに1つの制限があり、すべてのクライアントのユーザーごとに別の制限があります。リフレッシュトークンは長期的なストレージに保存し、有効である限り使用し続ける必要があります。アプリケーションが要求する更新トークンが多すぎると、これらの制限に達する可能性があります。その場合、古い更新トークンは機能しなくなります。
このページから：https : //developers.google.com/youtube/v3/guides/authentication#installed-apps
これはyouTubeドキュメント（他のAPIドキュメントよりもはるかに優れていることがわかります）によるものですが、すべてのGoogleアプリで同じだと思います。
これを見てください：
更新トークンは、ユーザーがアクセスを取り消すまで有効です。このフィールドは、access_type = offlineが認証コード要求に含まれている場合にのみ存在します。
でhttps://developers.google.com/accounts/docs/OAuth2WebServer
2017年のある時点でルールが変更されたので、最良の答えは製品によって異なると思います。たとえば、Gmail APIでは、Oauth 2.0更新トークンはパスワード変更時に期限切れになります。こちらをご覧くださいhttps://support.google.com/a/answer/6328616?hl=en
以前はAPIアクセスをセットアップし、新しいGmailユーザーをセットアップするときに更新トークンを生成していたため、メールをアーカイブすることができました（法律でこれを行う必要があります）が、パスワードを変更するとすぐに、更新トークン取り消されます。
おそらくYouTube、マップの場合、更新トークンはまだ本当に長持ちしますが、Gmail APIの場合は短いトークンを使用してください。
リフレッシュトークンの主な概念は、トークンが長期間持続し、期限が切れないことです。
アクセストークンには有効期限があり、有効期限が切れます。有効期限が切れると、更新トークンを取得できます。これは、ユーザーが自分のアカウントを取り消すまで何度も使用されます。
これを以下からお読みください：https : //developers.google.com/identity/protocols/oauth2#expiration 付与された更新トークンが機能しなくなる可能性を予測するには、コードを記述する必要があります。次のいずれかの理由により、更新トークンが機能しなくなる可能性があります。
ユーザーがアプリのアクセスを取り消しました。更新トークンは6か月間使用されていません。ユーザーがパスワードを変更し、更新トークンにGmailスコープが含まれています。ユーザーアカウントが許可された（ライブ）リフレッシュトークンの最大数を超えました。現在、クライアントごとのユーザーアカウントごとに50の更新トークンの制限があります。制限に達した場合、新しいリフレッシュトークンを作成すると、警告なしに最も古いリフレッシュトークンが自動的に無効になります。この制限はサービスアカウントには適用されません。
また、ユーザーアカウントまたはサービスアカウントがすべてのクライアントにわたって保持できる更新トークンの総数には、より大きな制限があります。ほとんどの通常のユーザーはこの制限を超えることはありませんが、開発者のテストアカウントは制限を超える可能性があります。
さらに調査を行ったところ、最初の「オフライン」リクエスト中に、Googleアクセストークンが更新トークンの取得に使用されているようです。これ以降、更新トークンを使用して新しいアクセストークンが発行されます。この考え方は、アクセストークンは短期的なトークンですが、長期的な更新トークンによって更新できるというものです。これにより、URLの「コード」変数を要求する必要がなくなります。これには、2つのエンドポイントアプローチが必要であり、参照元ベースの要求を使用して開始する必要があります。
http://www.jensbits.com/2012/01/09/google-api-offline-access-using-oauth-2-0-refresh-token/
Dropboxなどの一部のREST APIサービスは、永続的なアクセストークンを発行しますが、Googleは短期間のアクセストークンを発行します。PayPalは妥協案を使用して、URIリファラーを適用せずにアクセストークンを取得できるようにします。つまり、プロセスを開始するためにリンクをクリックする必要なく、アクセストークンを取得できます。Googleの方法論では、APIルーチンは、使用する必要がある場合にのみ呼び出す必要があります。基本的に、コールはリファラーベースの手順を介して開始されます。これは、有効期間が短いアクセストークン、またはチェーンで更新する必要があるアクセストークンを発行することによって制御されます。これにより、開発者はシステムの流れ方についてより慎重に考える必要があります。