谷歌 OAuth 2.0：刷新access_token

Question

我有一個基於服務器的應用程序，它將在用戶的谷歌日歷上發布約會日期。

新用戶通過一個過程來授予我的應用程序訪問他們日歷的權限。 我還沒有獲得谷歌的批准，所以我仍然低於 100 個用戶的限制（我大約有 30 個用戶）。

我使用 HTTP 並在我最初的 OAuth 請求中提供了以下內容：

sprintf(TM.txt, "code=%s&client_id=%s&client_secret=%s&redirect_uri=%s&grant_type=authorization_code",

最近幾個月 - 該過程通常將用戶重定向到谷歌，在那里他們輸入他們的 email 和密碼，然后使用訪問令牌和刷新令牌返回到我的服務器。 （我使用刷新令牌的存在來確定服務器是否具有長期訪問權限）。

最近初始請求沒有被重定向到谷歌，服務器返回一個訪問令牌而不是刷新令牌。

在 stackoverflow 上搜索過去的帖子，我發現建議將以下內容添加到請求中，但沒有返回刷新令牌： &access_type=offline&prompt=consent

問題

1. 請求過程中有什么變化嗎？

2. 像過去一樣，我缺少什么來接收刷新令牌？

3. 我知道如果一個刷新令牌在過去被磨碎 - 在用戶通過以下方式取消原始批准之前無法重新獲取新令牌：

   https://security.google.com/settings/security/permissions?pli=1

我已經查看了我們已獲得許可並擁有刷新令牌的用戶的這些權限 - 但我沒有看到我的應用程序被聲明為第三方應用程序。 我的應用程序應該如何顯示，以便在需要該操作時可以將其關閉？

謝謝

這是已經運行了 3 個月的代碼：

sprintf(TM.txt, "code=%s&client_id=%s&client_secret=%s&redirect_uri=%s&grant_type=authorization_code",
    JSTR *Code, 
    "323191532401-fcagbr2kfmofgil2i2qch53p1whe27g9.apps.googleusercontent.com",
    "j3dIGjj-c5d17bE-HVb2d67R",
    "https://knowledgeispower.biz:8888/GoogleOuath" );

我已經更改了上面的值，所以它們不是實際使用的值。

Answer 1

目前尚不清楚“初始 OAuth 請求”是什么意思。 OAuth2流程如下：

• 您將用戶重定向到授權 URL （授權請求）
• 您的用戶被谷歌重定向到您的重定向 URL code
• 您使用code向令牌 URL （令牌請求）發出直接 HTTP 請求

假設您所說的“初始 OAuth 請求”是授權請求，您的授權 URL 的結構是不正確的：

• 您不應該在授權 URL 中包含code參數（該代碼作為查詢參數返回到您的redirect_uri以在令牌請求中使用。請注意，我什至不確定這個值是什么）
• 您不應在授權 URL 中包含client_secret 。客戶端機密是一個秘密，只有您的應用程序知道。 如果您已將其包含在 URL 中，您應該假設它已被泄露，並且您需要來自 Google 的新憑據。 client_secret應僅包含在向 Google 發出的服務器端請求中，以授權您的應用程序。
• 您必須包含scopes參數。 這會告訴 Google 您的應用程序請求的權限
• 如果您需要刷新令牌，則必須包含access_type=offline 。 沒有它，谷歌將不會返回一個。
• 如果您之前可能已請求該用戶的訪問權限，但沒有為他們存儲刷新令牌，則您應該包括prompt=consent 。 使用prompt=consent ，Google 將生成另一個刷新令牌並將其返回給您的應用程序，即使用戶之前已授權它也是如此。

另一方面，如果您所說的“初始 OAuth 請求”是令牌請求，那么問題很可能是您將prompt和access_type參數添加到令牌請求，而不是授權請求（需要它們的地方） ).

您也可以考慮使用托管的 OAuth 提供程序，例如Xkit （我工作的地方），用於此類操作。 使用托管提供商，您不必擔心 Google 會更改其參數，一切都會為您處理。 只需一個請求即可獲得始終有效的訪問令牌。