ここ数か月で、Google Apps スクリプト内の OAuth2.0 認証に慣れてきましたが、最近の異常に戸惑いました。フュージョン テーブルのフロントエンドとして機能するスタンドアロンの Web アプリがあります。Web アプリは、スクリプトと融合テーブルの所有者として「実行」するように設定されており、融合テーブルは外部ユーザーに表示アクセスを許可します。プログラムは承認を検出し、必要に応じてプロンプトを表示し、利用可能な場合は更新トークンを使用します。スクリプトとフュージョン テーブルを所有するアカウントから実行すると、すべて問題ありません。
Web アプリを公開したら、外部アカウントからテストしたところ、問題なく動作しました。その後、更新トークンがスクリプト所有者の UserProperties から削除されました。アプリが外部アカウントから再度実行されると、承認が求められ、正しく承認されました (スクリプト所有者の UserProperties に新しいトークンが保存されます)。ただし、API への次の POST 呼び出しで 403-Forbidden エラーが発生しました。この時点で、トークンが手動でクリアされ、スクリプト所有者として再認証されるまで、アプリはすべてのアカウント (スクリプト所有者のアカウントを含む) から 403-Forbidden エラーを受け取り続けます。
これらのトークンが有効でないのはなぜですか? アプリはスクリプト/フュージョンの所有者として「実行」されているため、プログラムで受け取ったトークンは、スクリプト/フュージョンの所有者によって承認されたものと同じくらい有効であると予想されます。私の期待が間違っている場合、複数のユーザーに対してこの状況を防ぐにはどうすればよいですか?
アップデート
私はこれについてさらに多くの注目を集め、ここで共有したいいくつかの関連する問題を特定しました. まず、トークン (更新とアクセス) を手動で削除して、アプリの承認機能をテストしました。その後の認証で更新トークンが返されませんでした (これにより、過剰なプロンプトが表示されました)。これは、Google API の意図的な結果であることがわかりました。リフレッシュ トークンを返すために必要な要求パラメーターは別として、リフレッシュ トークンは最初のユーザー プロンプトと認証でのみ返されることがわかりました (参照はこちら)。別の更新トークンを取得するには、アクセス権を取り消して再承認するか、承認プロンプトを強制する必要がありますリクエストで。トークンが最初の承認要求を行っているユーザーに「添付」されていることがより明確になったことを修正したら。スクリプト/テーブルの所有者が取得した更新トークンを保持している限り、外部ユーザーはそのスクリプトを使用 (および更新トークンを使用してプログラムで再承認) できます。要点に戻ります。更新トークンを紛失した場合は、残りのすべてのトークン スクラップを手動で削除し、スクリプト/テーブルの所有者としてログインし、アプリへのアクセスを取り消してから、再承認する必要があります。
以下のZigの回答によると、それはまさにその通りです。その非常に手動のプロセスをプログラムで防止する方法はありませんか?