有很多事情可以影响解决这个问题的最佳方法;根据提供的信息,可以展示适用的选项并提出一些建议,但如果没有所有上下文,则很难做出最终选择。
TL;DR在基于浏览器的应用程序中,最终用户会获得用户名/密码凭据,并且应用程序需要代表用户调用 API 您可以使用隐式授权或资源所有者密码凭据授权 (ROPC)。 ROPC 的使用应进一步限制在应用程序与控制用户凭据的实体之间高度信任的客户端应用程序中。
客户端凭据的使用完全超出了范围,授权代码授予可能不会比隐式授予对基于浏览器的应用程序所关注的内容带来任何好处,因此通过消除过程,我们有两个符合条件的授予。
资源所有者密码凭据授予
(查看Auth0 ROPC Overview以获取有关步骤的完整详细信息)
此授权主要是在 OAuth 2.0 中引入的,目的是为存储用户名/密码凭据的应用程序提供无缝迁移路径,以便无需不断要求用户提供凭据即可访问用户资源。可以想象,以纯文本形式存储密码是一个很大的禁忌,因此通过非常简单的迁移路径(使用此授权将存储的凭据与令牌交换存储的凭据)来停止这样做将是一个很大的改进。
但是,访问令牌会过期,因此继续获取新令牌以进行访问的方法是使用刷新令牌。将刷新令牌保存在存储中比密码更好,但它们通常仍然是长期存在的凭据,因此存储这些类型的令牌的行为有额外的安全考虑。因此,通常不建议在基于浏览器的应用程序中保留/使用刷新令牌。
如果您选择此授权,您需要决定访问令牌到期时会发生什么。
隐式授权
(查看Auth0 Implicit Grant Overview以获取有关步骤的完整详细信息)
此授权是授权代码授权的简化版本,专门针对在浏览器环境中实现的应用程序,因此它似乎更适合您的场景。
另一个好处是,在第一次用户身份验证后,可以透明地获取新的访问令牌,更具体地说,通过让授权服务器管理会话的一些概念,任何对已通过身份验证且已同意的用户的隐式授权请求提供无需用户交互即可自动完成授权。
结论(也就是基于我所知道的可能不够充分的意见)
作为一般建议,我会选择隐式授权而不是 ROPC 授权。