我有点困惑,因为我不知道我应该为我的具体情况使用什么类型的资助。
我有一个前端React应用程序,后端使用Spring Boot。此外,还有一个独立的Spring OAuth2授权服务器。
React应用程序将是一个普通的公共Web应用程序,其中身份验证需要用户名和密码凭据。
我应该使用什么类型的补助金?资源所有者密码凭据是否是一个不错的选择?
答案 0 :(得分:3)
有很多事情可以影响最好的方法来解决这个问题;根据提供的信息,可以展示适用的选项并做一些推荐,但如果没有所有的背景,很难做出明确的选择。
TL; DR 在基于浏览器的应用程序中,最终用户获得用户名/密码凭据,应用程序需要代表用户调用API 您可以使用隐式授权或资源所有者密码凭据授权(ROPC)。 ROPC的使用应进一步限制在应用程序与控制用户凭证的实体之间存在高度信任的客户端应用程序。
客户端凭据的使用完全超出范围,授权代码授予可能不会对基于浏览器的应用程序的隐式授权带来任何好处,因此通过消除过程我们有两个合格的授权。
(查看Auth0 ROPC Overview以获取有关步骤的完整详情)
此授权主要在OAuth 2.0中引入,作为为存储用户名/密码凭据的应用程序提供无缝迁移路径的方式,以便在不经常要求用户提供凭据的情况下访问用户资源。可以想象,以纯文本形式存储密码是一个很大的问题,因此有一种方法可以通过一个非常简单的迁移路径(使用此授权将存储的凭证与令牌交换)来停止这样做,这将是一个很大的改进。
但是,访问令牌过期,因此继续获取新令牌以进行访问的方法是使用刷新令牌。在存储中保留刷新令牌优于密码,但它们通常仍然是长期凭证,因此存储这些类型令牌的行为具有额外的安全性考虑因素。因此,通常不建议在基于浏览器的应用程序中保留/使用刷新令牌。
如果您选择此授权,则需要确定访问令牌过期时会发生什么。
(查看Auth0 Implicit Grant Overview以获取有关步骤的完整详情)
此授权是授权代码授权的简化版本,专门针对在浏览器环境中实现的应用程序,因此它似乎更适合您的场景。
另一个好处是获得新的访问令牌可能在第一次用户身份验证后透明地发生,更具体地说,通过让授权服务器管理一些会话概念,对已经过身份验证且已经同意的用户的任何隐式授权请求提供授权可以自动完成,无需用户互动。
作为一般性建议,我会选择对ROPC拨款的隐性拨款。