SPA中的OpenId Connect renew access\u令牌

Question

尝试在包含以下组件的Web应用程序中实现OpenId连接

• 身份提供者

身份提供程序和资源服务器是同一个应用程序。

SPA使用Password Flow获取access_token并存储到cookie中。将access_token存储到cookie中具有安全线程，但情况不同。

问题

IdP发布的access_token在30分钟后过期，SPA需要更新令牌，而无需再次询问用户凭据。

解决方案

IdP返回刷新令牌以及访问令牌。每当SPA从资源服务器获取401时，它都会向IdP发送刷新令牌，并返回get的新访问令牌。

问题

向SPA发送刷新令牌是一种错误的做法。

单页应用程序（通常实现隐式授权）在任何情况下都不应获取刷新令牌。原因是这条信息的敏感性。您可以将其视为用户凭据，因为刷新令牌允许用户本质上永远保持身份验证。因此，您不能在浏览器中使用此信息，必须将其安全存储。

建议的解决方案

当访问令牌过期时，如果用户的SSO会话尚未过期，则可以使用静默身份验证来检索新令牌，而无需用户交互。

我认为当IdP和资源服务器是同一个应用程序时，静默身份验证不适用于密码流。IdP发布的access_token只是过期后可用于对资源服务器/IdP进行授权的信息，客户端如何说服IdP发布新的access_token？（无需发送refresh_token）

找到angle-oauth2-oidc库，它使用refresh_token更新access_token。

在这种情况下，续订access\u token的最佳做法/解决方案是什么？

技术细节

• 身份提供程序-ASP。NET核心Openiddict库

Answer 1

除了之前的回答之外，OAuth工作组最新的SPA指南不再建议使用隐式流。

如果您有简单的共享域应用程序（单个域上的IdP、RS和客户端），那么您应该考虑根本不使用OAuth。来自文档：

OAuth和OpenID Connect在这种部署场景中提供的好处很少，因此建议您重新考虑在这种情况下是否需要OAuth或OpenID Connect。会话身份验证的优点是具有较少的移动部分和较少的攻击向量。OAuth和OpenID Connect主要是为第三方或联合访问API而创建的，因此可能不是同一域场景中的最佳解决方案。

如果您在SPA中使用OIDC/OAuth，他们建议使用PKCE的身份验证代码流。

Answer 2

使用资源所有者密码凭据流会破坏刷新令牌存储参数：SPA现在必须将资源所有者凭据存储在一个安全的地方，而不是无法将刷新令牌存储在一个安全的地方（假设您希望避免频繁向用户请求用户名/密码）。隐式补助金是为SPA设计的，所以最好还是坚持使用它。

Answer 3

单页应用程序不得接收刷新令牌。这已经在OAuth 2.0和OpenID Connect中建立了规则。

我在这里看到的一个好的选择是使用隐式流。这将建立从浏览器到身份提供商的前端通道会话。使用密码授予类型，您可以进行反向通道调用（POST），因此您不会获得此类会话。

通常这是一个cookie，它指向有关以前登录状态的信息（这些是身份提供者的详细信息）。流程完成后，SPA将收到访问令牌。如您所知，它将过期。但是一旦发生这种情况，SPA可以触发另一个隐式流，但这次使用提示符查询参数。

提示

ASCII字符串值的空格分隔、区分大小写的列表，用于指定授权服务器是否提示最终用户重新验证和同意。定义的值为：无、登录、同意和选择\u帐户

如果您的身份提供者维护一个长期会话（例如：几个小时或几天），或者如果它维护一个记住我的cookie，SPA可以使用提示=无，使其跳过身份提供者的登录步骤。基本上，您可以通过此获得基于浏览器的SSO行为。