从0开始构建一个Oauth2Server服务 <22> 应用列表及撤销授权

展现用户授权的应用

一旦用户开始授权多个应用程序，允许许多应用程序访问他们的帐户，就有必要提供一种方法来允许用户管理具有访问权限的应用程序。这通常在帐户设置页面或帐户隐私页面中呈现给用户。

OAuth 2.0 规范中没有任何内容要求用户能够撤销访问权限，甚至没有建议如何执行此操作，因此我们将查看几个主要的 API 提供商以获取有关如何完成此操作的灵感。

大多数提供商都有一个页面，其中列出了用户已授权其帐户使用的所有应用程序。通常会显示一些关于应用程序的信息，这些信息旨在为用户提供有关此应用程序何时以及为何可以访问的上下文。

谷歌

Google 在https://security.google.com/settings/security/permissions提供了您已在您的帐户上授权的应用程序列表。

该列表显示应用程序图标、名称和应用程序被授予的范围的摘要。单击其中之一可展开该部分以显示更多详细信息。

GitHub

GitHub 在https://github.com/settings/applications提供了您已授权的应用程序列表。

GitHub 提供的列表包括应用程序上次使用时间的描述，让您了解在一段时间未使用应用程序时是否可以安全地撤销该应用程序的凭据。

撤销授权 revoking access

出于多种原因，您可能需要撤销应用程序对用户帐户的访问权限。

• 用户明确希望撤销应用程序的访问权限，例如，如果他们发现他们不想再使用的应用程序列在他们的授权页面上
• 开发人员想要撤销其应用程序的所有用户令牌
• 开发人员删除了他们的应用程序
• 作为服务提供商，您已确定某个应用程序受到威胁或存在恶意，并希望将其禁用

根据您实现生成访问令牌的方式，撤销它们将以不同的方式工作。

令牌数据库

如果将访问令牌存储在数据库中，那么撤销属于特定用户的所有令牌就相对容易了。您可以轻松编写查询来查找和删除属于用户的令牌，例如在令牌表中查找他们的user_id. 假设您的资源服务器通过在数据库中查找访问令牌来验证访问令牌，那么下次被撤销的客户端发出请求时，他们的令牌将无法验证。

jwt令牌

如果你有一个真正无状态的令牌验证机制，并且你的资源服务器在不与另一个系统共享信息的情况下验证令牌，那么唯一的选择就是等待所有未完成的令牌过期，并阻止应用程序生成新令牌通过阻止来自该客户端 ID 的任何刷新令牌请求来针对该用户。这是使用自编码令牌时使用极短寿命令牌的主要原因。

如果你能负担得起某种程度的状态，你可以将令牌标识符的撤销列表推送到你的资源服务器，并且你的资源服务器可以在验证令牌时检查该列表。访问令牌可以包含一个唯一的 ID（例如声明jti），可用于跟踪各个令牌。如果你想撤销一个特定的令牌，你需要把那个令牌jti放到一个列表中，某个地方可以被你的资源服务器检查。当然，这意味着您的资源服务器不再进行纯粹的无状态检查，因此这可能不是适用于所有情况的选项。

您还需要使与访问令牌一起颁发的应用程序的刷新令牌无效。撤销刷新令牌意味着应用程序下次尝试刷新访问令牌时，将拒绝对新访问令牌的请求。