asp.net - OpenID Connect : Proper way of authenticating user - ID token or Access token? 刷新 ID token ？

Question

在我们的 Web 应用程序 (ASP.NET) 中，我们使用 OpenID Connect 和授权代码流:

1. 用户被重定向到身份提供者(例如 Azure AD)，进行身份验证，
2. 授权码被回传到我们网络应用程序的一个页面。
3. 然后，我们的网络应用程序使用授权代码从身份服务器检索刷新 token 、ID token 和访问 token 。这些作为 cookie 存储在客户端上(HttpOnly 标志设置为 true)。这是为了避免对服务器状态的依赖，以防负载平衡器将用户路由到不同的 Web 服务器。
4. 当用户访问页面时，我们会验证 ID token 的签名和有效期，并根据应用程序中的用户数据库检查我们用于身份的声明(例如电子邮件地址或 UPN)。

这有效——除了我们无法刷新 ID token ，因此用户在 1 小时后超时，需要重新登录。根据 OpenID Connect 规范，当使用 token 端点刷新 token 时，并非所有 OpenID Connect 提供商都会提供新的 ID token 。

目前我们看到的替代方案:

1. 根本不要使用 ID token 。使用访问 token 查询用户声明的 UserInfo 端点，并将其缓存在服务器上(在缓存未命中时，例如，如果路由到不同的 Web 服务器 - 只需使用 cookie 中提供的访问 token 再次请求 UserInfo)。由于可以刷新访问 token ，因此这可能会正常工作。
   • 优点:我们得到一个正确刷新的 token ，由服务器验证。
   • 缺点:并非所有声明(例如 aud 和 iss)都由 UserInfo 端点提供，至少对于 Azure AD 是这样。
2. 不要验证 ID token 是否过期，只要它不早于例如12小时。
   • 优点:简单，只需很少的努力即可改变当前的行为。拥有我们今天也拥有的所有权利。
   • 缺点:可能存在安全风险？评论？

那么在较长时间内保持用户登录的推荐方法是什么？将访问 token 与 UserInfo 端点一起使用是否是合适的解决方案？

Answer 1

首先您需要了解每个 token 的用途。 ID Token 供客户端(应用程序)使用。它包含您可以验证以验证最终用户身份(身份验证)的声明。

访问 token 用于授权。它旨在用于 protected 资源(例如:- 受 OAuth 2.0 token 保护的 API)。当 API 收到 token 时，它必须对其进行验证并授予访问权限。

刷新 token 用于刷新访问 token 。现在 OpenID Connect 作为 OAuth 2.0 的扩展，允许使用刷新 token 。但是正如您所了解的，ID token 可能会或可能不会被刷新。我亲眼看到 Auzre AD 没有刷新 ID token 。

最好的解决方案是在前端和后端之间使用 session 。在验证来自 token 请求的 token 后设置此 session 。 session 存储可以保存最初发送的访问 token 。与此同时，存储刷新 token 。您可以简单地验证 ID token 并将其丢弃(假设您将所有必需的信息存储到 session 中)。确保此 session 是 HttpOnly 和安全的(仅限 Https)。 session 过期时间可以等于访问 token 有效期。

访问 token 过期后，您可以使用刷新 token 获取新 token 。无论何时，您的后端都可以将访问 token 附加到来自后端的 API 请求。这样您就永远不会将访问 token 和刷新 token 暴露给前端。