不要使用Resource Owner Password Credentials
文章链接在这里
前言最近公司项目在做一些重构，因为公司多个业务系统各自实现了一套登录逻辑，比较混乱。所以，现在需要做一个统一的鉴权登录中心，准备用IdentityServer4来实现。看到一些文章，觉得可以翻译记录一下。
Resource Owner Password Credentials简称ROPC。
首先说一下OAuth2.0 里面有几种Grant Type，每种有特定的使用场景.
Authorization Code
Implicit
Password(也就是标题上讲的那种)
Client Credentials
Device Code
Refresh Token
正文
就顺着文章思路看一下吧。
当你咨询别人自己是否需要用ROPC这种grant type，标准的答案肯定是“不一定”。当然这个答案是正确的。但是我的观点是“不”。不幸的是，现在很多人看到username 和 password 就会激动的说 这就是我想要的（注：我当时也就是因为看到这两个词就觉得这是我应该要用的类型）。他们花了大量的时间实现了这种方式，然后我又花了大量的时间来说服他们这是一个差劲的主意。
下面我们来看看ROPC这种类型，为什么他这么有诱导性，同时我们能做什么来说服别人不要使用这个type这个观点。
为什么ROPC存在ROPC适合的场景是这样的：用户信任client（client就是需要访问用户个人信息的程序），这种client可能是一些高权限的应用。授权服务器应该特别关注这种情况。并且只有在其他类型不启用的情况下使用它。
—引用自
好，这里已经说的很清楚了。其一，用户要相信client。我们可以把他理解为你的系统是运行在自己系统/设备。
ROPC通常用于迁移以前的直接单向的验证方式比如HTTP Basic或者Digest authentication。替换以前的存用户凭证的方式改为存access token的方式。
—引用自https://tools.ietf.org/html/rfc6749#section-4.3
这是ROPC的另一个用途。老系统的迁移。实现了这种方式，我们可以立马就体会到access token方式带来的好处，比如有效期，scope 访问控制，以及所有OAuth相关的内容。慢慢的就爱上了OAuth。查看我的文章了解为什么不要用类似Http Basic的方式去做验证/鉴权。
为什么你不应该使用ROPC下面来模拟一下情况。当你集成了OAuth Provider 或者是OpenID Connect Provider，委托认证应该是由OAuth系统来处理。当使用了ROPC，就没有办法知道用户是否真正的发起了请求。ROPC不是一种认证方式。
同时，这种方式在引导你的用户养成一个坏的习惯。他很像一种网络欺骗攻击。一个不知名的程序要求你的用户提供其他程序的凭证。试想一个程序让你输入你谷歌或者facebook的凭证，而不是重定向到谷歌或者fb的页面的情况。
如果你的鉴权服务器和client程序都是你自己，那相对来说可以原谅一些。但是如果你让其他外部的client也使用相同的方式，那么就是把用户凭证暴露给外部的应用了。文档里面也有关于密码有可能被有意或无意的泄露的风险。
client 有可能滥用密码，或密码有可能无意中被攻击者获取。
—引用自https://tools.ietf.org/html/rfc6749#section-10.7
我们这里也默认client程序会通过客户的凭证请求合理的api scope，并通知用户client在访问的内容。用户对授权过程是不可控的（因为只要一步输入用户名密码的过程）。结束了之后，client拿着token想干嘛就干嘛。虽然我们可以通过控制scope的方式来限制client的访问。当时client对用户资源的访问仍然是不可见的。
如果你使用了ROPC而不是其他的，那就无法实现单点登录。用户实际上没有在授权服务器做真正的认证（注：可能真正的认证包括其他比如scope显示之类的），你只是在使用获取token端口。如果你在使用OpanID Connect，那么就无法通过这种方式来获取用户的identity token。
和共享凭证以及Http Basic验证方式类似，ROPC同样限制了验证的方式，这里就只能用username 和 password。多因子验证的方式变得不可用。
认证服务和client应该尽可能少的使用这种类型。
—引用自https://tools.ietf.org/html/rfc6749#section-10.7
在使用ROPC之前应该问自己的问题因为这是一种有瑕疵的grant type，所以，只有在实在没有选择的情况下才能使用。下面有几个问题需要考虑的。
你的程序是否需要考虑历史应用。如果不需要考虑，就不要使用ROPC。2012年之后的程序就不要使用了。
你的应用是否可以通过浏览器访问。如果是，请不要使用。
你的用户是否信任client。SPA是运行在浏览器端的，请不要使用ROPC。（注：可以伪造一个页面，用户输入用户名+密码）。
是不是需要在意安全问题。如果是，就不要使用。
下面的借口是无效的我现在没时间。。
我只有一个app。