Otuth2 - 每个请求是否都会发送到授权服务器进行令牌验证？

Question

对 Oauth 是否更多地用于身份验证有疑问。

1. 我访问一个网站
2. 它将我重定向到 Oauth 提供商（例如 google（提供商））进行登录
3. 我能够成功登录，提供商返回一个包含资源信息和其他内容的令牌

几个问题

1. 通常，令牌刷新时间可能长达 2 个月（https://learn.microsoft.com/en-us/linkedin/shared/authentication/authorization-code-flow?context=linkedin/context）。客户端可以控制token的有效期吗？
2. 当用户访问应用程序时，应用程序是否每次都会访问提供商来验证令牌，或者是否能够在本地解码令牌并允许用户访问（类似于自包含的 JWT）？
3. 如果每次都影响提供商，这不会影响可扩展性吗？我的理解是每次都必须联系提供商
4. 以防万一，如果不需要在每个请求上访问提供者 - 当我们撤销提供者的权限时，访问将如何被拒绝。

我有点迷失了

• 当第三方应用程序仅使用令牌进行身份验证时的用例 - 如果每个请求最终都到达提供商，并且如果每个请求没有最终到达提供商，则应用程序如何扩展，那么如何通知应用程序有关已撤销的密钥？
• 如果查找资源（例如来自 Facebook 的提要） - 很明显它将访问资源服务器，资源服务器是否始终使用授权服务器验证令牌？

Answer 1

1. 令牌超时期限通常在授权服务器中为每个应用程序配置，然后将其应用于访问该特定应用程序的所有请求。

   如果授权服务器能够确定客户端的信任级别，例如客户端是被管理设备，则授权服务器可以根据客户端的设置颁发具有更长/更短超时时间的令牌。可以从Azure AD 条件访问找到一个示例。

2. 有两种方法可以确定访问令牌的有效性。

   1. 使用自编码访问令牌，例如 JWT。在这种情况下，应用程序服务器可以验证访问令牌的完整性，而无需直接与授权服务器协商。

   2. 一些授权服务器为应用程序服务器实现令牌自省端点以检查访问令牌的有效性。但并非所有授权服务器都提供此功能。

3. 我相信是这样，但抱歉我找不到这方面的现实世界参考。请注意，即使Azure AD也不提供令牌自省端点，因此相当一部分 OAuth2 应用程序应使用自编码访问令牌，这确实可以缓解此可扩展性问题。

4. 这就是为什么访问令牌的生命周期应保持较短，并且客户端应定期从授权服务器刷新访问令牌以维持访问授权。