access_type=online oauth 模式（无刷新令牌）应该如何工作？答案

【问题标题】：How is the access_type=online oauth mode (no refresh token) supposed to work?access_type=online oauth 模式（无刷新令牌）应该如何工作？
【发布时间】：2019-01-16 01:53:16
【问题描述】：

这个问题与上一个问题Google OAuth: can't get refresh token with authorization code 有很多共同点（如果它被认为是重复的，我不会被冒犯）但有一些区别：该问题使用 Javascript 和 PHP 库，而我' m 两者都不使用。该问题想知道如何获取刷新令牌，并且我想知道我是否应该想要一个刷新令牌，或者没有刷新令牌的模式打算如何工作。

我正在遵循本指南：

https://developers.google.com/identity/protocols/OAuth2WebServer

目标是允许用户将文件从 Google Drive 上传到我的网络应用程序。

我没有使用 Google 最喜欢的一种编程语言，所以我没有一个库来抽象出与 Google 的所有交互。我需要知道 HTTP 请求实际上应该是什么样子。

授权请求中的参数之一是access_type。描述说

如果您的应用程序需要在用户不在浏览器时刷新访问令牌，请将值设置为 offline。

我不需要这样做（我只想在用户选择它后立即在我的服务器上检索一个文件）所以本着不要求比你真正需要的更多权限的精神，我使用了@987654324 @。这给了我一个访问令牌，没有刷新令牌。我已成功使用访问令牌向 Google Drive 发出一些请求。

用户第二天回来并尝试上传另一个文件。在处理来自用户的这个请求时，我向 Google Drive 发出请求。访问令牌已过期，所以我收到了 401。接下来会发生什么？

我的猜测是我应该假装这是一个全新的用户，然后再次通过完整的授权过程发送给他们。这意味着我必须中止用户尝试执行的任何操作，使用所有参数（scope、client_id 等）将它们重定向到 https://accounts.google.com/o/oauth2/auth，并在 state 参数中嵌入足够的信息，我可以当用户绕道返回时恢复原始请求。

这似乎相当困难（特别是关于在某个任意点保存和恢复我的应用程序状态的部分）。这是一个足够大的障碍，应该在某个地方进行解释。但是access_type 参数的描述并没有说明需要在任何地方插入授权重定向。它只是说用户必须“在场”。

【问题讨论】：

关于“我只想在用户选择后立即在我的服务器上检索文件”，“我的服务器”是您的 Google Drive？您想让用户在 Web 应用程序中使用从您的 Google Drive 下载的文件。我的理解正确吗？
@Tanaike “我的服务器”怎么会是 Google Drive？ Google 云端硬盘位于 Google 的服务器上。我不是谷歌。我不明白你在描述什么安排，但这不是我链接到的开发人员指南所涵盖的安排。
我真的很抱歉我的技能不好。我曾询问您要使用的文件的位置。我原以为这些文件在您帐户的 Google Drive 中。如果这是我的误会，我能问一下“我的服务器”吗？

标签： google-oauth

【解决方案1】：

您正在使用正确的实现。如果您不打算在用户不使用应用程序时发出请求，则不需要离线访问。问题是访问令牌会在 1 小时内过期。因此，如果用户离开应用程序并稍后回来，您需要生成新的访问令牌。

如果用户已授权您的应用程序，使用您的配置调用此 URL 应返回一个新的有效访问令牌：

https://accounts.google.com/o/oauth2/v2/auth?
 scope=scopes&
 include_granted_scopes=true&
 state=state_parameter_passthrough_value&
 redirect_uri=http://oauth2.example.com/callback&
 response_type=token&
 client_id=client_id

【讨论】：

如果我想重做初始授权，这看起来与我将用户重定向到的 URL 非常相似。（唯一看起来不同的部分是 response_type=token 与 response_type=code。）所以这必须是重定向，导致正在进行的操作被中止？
response_type=code 在请求离线访问时是必需的。我忘了告诉你，你需要检查this documentation。在那里，使用 Oauth2 端点，您将看到您需要生成该 url 并将用户重定向到它以获得访问令牌。我一直使用 JS 库，所以我不是 100% 确定，但恐怕您需要使用 oauth2 端点将用户重定向到该 url。
现在对我来说开始变得更有意义了，因为我已经意识到我试图避免的事情（用户可见的重定向）是向 Google 提供用户存在的证据.不过，我认为“客户端 Web 应用程序”指南不适用于我。
我了解您的情况，使用 JS 库它工作得很好......无论如何，您是否尝试生成一个新的访问令牌来向该 url 发出请求？只是为了确认我是对的，以防我将来需要使用此解决方案。
我可以确认重定向到/o/oauth2/v2/auth URL 确实提供了新的访问令牌，而实际上并未向用户显示批准表单。但无论如何它都必须发送给用户，这意味着我必须中止正在进行的操作并在重定向后重新启动它。为避免复杂性爆炸式增长，我将改用刷新令牌。