假设我们有一个支持“读”和“写”范围的 OAuth2 实现。
我检索具有“读取”范围的访问令牌“f482c829”。如果我改变主意，现在想要读+写权限并再次使用“读”和“写”范围授权，你会：
如果您每次为每个范围创建一个新令牌，您最终必须在每个授权和不同的权限存储多个访问令牌。我一直犹豫要不要这样实施。
不幸的是，OAuth2 规范（从草案 12 开始）没有解决任何这些问题。
在 facebook 的情况下，资源服务器与授权服务器基本相同。所以他们确实“使用现有令牌”的方式。它允许用户禁用 facebook.com 网站上的每个范围。关于刷新令牌，您不需要建立新的刷新令牌。（当然你可以这样做。）现有的刷新令牌也将与所有范围连接。
在 Google 的情况下（可能是 Yahoo!），资源服务器与授权服务器完全不同。许多资源服务器（Docs、Buzz 等）接受访问令牌建立的单一授权服务器。在这种情况下，“建立新令牌”的方式似乎更好。
在 Twitter 的情况下（也许你的情况也是如此），两者看起来都不错。
另外，无论如何，当用户撤销客户端访问权限时，您需要撤销客户端的所有令牌。用户不是在撤销“令牌”而是“客户”。
由于开发人员应该预先注册redirect_uri，因此在网站和移动设备上使用相同的客户端凭据似乎都很棘手。因此，我建议在这种情况下要求开发人员使用不同的客户端凭据。
假设应用程序的一个客户端（移动设备）需要只读访问权限，而另一个客户端（网站）也需要写入。这将要求客户端能够决定令牌请求的范围，因此提供者可以存储具有不同范围的多个令牌。
但是，是否要扩展现有令牌的范围取决于您。这意味着您可以为每个应用程序保留一个示波器。这也可以很容易地撤销用户对应用程序的访问。