訪問令牌失效後谷歌API無效請求

我有一個服務器端Node.js應用程序，使用googleapis包。用戶使用他們的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因爲用戶已經登錄的第一次，並點擊接受，我沒有保存刷新令牌（貌似我應該）。

所以，當達到expiry_date時，如果用戶試圖發出請求爲我們的東西保存到自己的谷歌驅動器，我得到一個錯誤信息：

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

我的2部分的問題：

我認爲我收到錯誤消息，因爲在我的OAuth客戶對象是的access_token過期（因爲令牌過期之前調用正常工作）。它是否正確？爲什麼錯誤信息不是更詳細？
在頂部的鏈接答案中，解決方案是再次強制接受提示，獲取刷新令牌並永久存儲它，並在過期時使用它來獲取新的訪問令牌。爲什麼這是一個更好的選擇，而不僅僅是檢查令牌是否過期，並且在我們想要調用API時讓用戶重新認證？哪種「正確」方式可確保我的登錄用戶始終能夠通過驅動器API調用來保存他們的文檔？

來源

2016-09-02 Georges Pompidou

它看起來像您使用的是過時的端點內省令牌，因爲'expires_in'確實是由谷歌在最近的端點 –

@HansZ實施的標準行爲。你能否在這裏澄清術語「端點」和「反思」？我在node.js上使用了最新版本的google apis客戶端。 –

對，400響應是因爲過期的訪問令牌。我不確定Google爲何不提供更多詳細信息，但服務通常使用400狀態碼來指示某種憑證問題。狀態碼的definition表示這是客戶端問題。
這兩種方法都有效，它們各有優缺點。您建議的客戶端重新認證方法具有使實現更簡單的優勢，因爲您不必存儲刷新令牌，也無需實施刷新過程。缺點是迫使用戶每小時重新認證不那麼方便用戶。至少他們會被重定向到您的應用程序，他們可能不得不明確登錄或重新授權。你只需要看一下權衡，並選擇最適合你的用例。

來源

2016-09-07 10:39:02

我的替代方案實際上只是強制用戶重新授權訪問令牌過期。這將消除請求「離線」訪問的需要，而我並不需要。爲了澄清，我的目標是甚至允許已登錄到我的Web應用程序超過一個小時的用戶將他們的數據保存到Google Drive（我們通過API執行操作）。必須將每個用戶的刷新令牌永久存儲在數據庫中對我來說似乎有點偏離 - 爲什麼我必須這樣做？ –

@GeorgesPompidou：如果您願意，您當然可以要求您的用戶每小時進行一次重新授權，但這對用戶不友好。沒有人希望被重定向到他們正在訪問的頁面，而且沒有人喜歡登錄。相比之下，存儲刷新令牌（您已經存儲訪問令牌）應該是微不足道的，並且這將允許您可以長時間更新授權而不會影響用戶。 –

訪問令牌存儲在內存數據庫中的會話中，並且是臨時的。據我的理解，刷新令牌需要存儲在我的應用程序的長期數據庫中，並與每個用戶相關聯，如果我只想提醒用戶一次權限。這一點，加上我需要「離線訪問」來獲取它（這就像我說的，我的應用程序不需要），這一事實對我來說似乎很陌生。這就是爲什麼我希望有一個更好的方式，我錯過了。 –

訪問令牌失效後谷歌API無效請求

回答

相關問題