アクセストークン後のGoogle APIの無効なリクエストの有効期限が終了しました。

Question

Thisは、私にこの質問をしてくれたコメントです。

私はgoogleapisパッケージを使用して、サーバー側のNode.jsアプリを持っています。ユーザーは自分のGoogleアカウントでログインし、自分のセッションにトークンを保存します。

{ access_token: '<AN ACCESS TOKEN>', 
    token_type: 'Bearer', 
    id_token: '<A LONG ID TOKEN>', 
    expiry_date: <A TIMESTAMP> } // why do some places say there's an expires_in instead of this 

を次のように私が得る資格情報は、ユーザーが既に最初にログインし、受け入れクリック、と私はリフレッシュトークン（私はべきだったように見える）を格納しなかったので何のrefresh_tokenはありませんです。

{ [Error: invalid_request] code: 400 } // ...no further details 

私の2部構成の質問：expiry_dateに達したときに、私たちは自分のGoogleドライブに何かを保存するために、ユーザが要求を作るしようとした場合

だから、私は、エラーメッセージが表示されます：

• は、私は（トークンの有効期限が切れる前に、コールが正常に動作しますので）私のOAuthクライアントオブジェクトでaccess_tokenは有効期限が切れているので、私はそのエラーメッセージが出てい前提としています。これは正しいです？なぜエラーメッセージが詳細ではないのですか？

• 上部のリンクされている回答では、もう一度Acceptプロンプトを強制し、更新トークンを取得して永続的に保存し、有効期限が切れたときに新しいアクセストークンを取得することです。トークンが期限切れになっているかどうかを確認するだけでなく、APIを呼び出すときにユーザーを再認証させるよりも、なぜこのオプションが優れていますか？ログインしたユーザーがドキュメントを保存するためにドライブAPI呼び出しを常に行うことができるようにする「正しい」方法はどれですか？

Answer 1

1. 右、400応答は有効期限が切れているため、アクセストークンです。私はなぜGoogleが詳細を述べないのか分かりませんが、サービスが400ステータスコードを使用して何らかの種類の資格情報問題を示すのは一般的です。ステータスコードのdefinitionは、それがクライアントの問題であることを示します。

2. どちらの方法も効果があり、それぞれに長所と短所があります。リフレッシュ・トークンを格納する必要がなく、リフレッシュ・プロセスを実装する必要がないため、クライアント側の再認証方法では、実装が簡単になるという利点があります。欠点は、1時間ごとに再認証するようにユーザーを強制することは、ユーザーフレンドリーではないことです。少なくとも、彼らはあなたのアプリから離れてリダイレクトされ、明示的にログインするか再認可する必要があるかもしれません。トレードオフを見て、ユースケースに最適なものを選ぶだけです。