不要使用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可能是一些高权限的应用。授权服务器应该特别关注这种情况。并且只有在其他类型不启用的情况下使用它。

—引用自 https://tools.ietf.org/html/rfc6749#section-4.3

好，这里已经说的很清楚了。其一，用户要相信client。我们可以把他理解为你的系统是运行在自己系统/设备。

ROPC通常用于迁移以前的直接单向的验证方式比如HTTP Basic或者Digest authentication。替换以前的存用户凭证的方式改为存access token的方式。

—引用自https://tools.ietf.org/html/rfc6749#section-4.3

这是ROPC的另一个用途。老系统的迁移。实现了这种方式，我们可以立马就体会到access token方式带来的好处，比如有效期，scope 访问控制，以及所有OAuth相关的内容。慢慢的就爱上了OAuth。查看我的文章保护api的错误方式了解为什么不要用类似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。
因为用户体验。不要因为你想自定义你的登录页在自己的应用上就使用这种类型。因为有其他出于安全角度的考虑。通常情况下，我们使用google或者ms的应用的时候，是直接保存应用页面并不是登录页面。

如果我还不能说服你

如果你还是想用这种granttype，请至少考虑以下的几点

加固token endpoint

因为ROPC需要直接访问token endpoint（获取token），攻击者会特别关注这个地址，所以，你需要实现一些类似请求拒绝，防止恶意尝试的策略。

理想状况下token endpoint一般不应该被这种事情所打扰，所以，默认的OAuth或者OpenID Connect Provider都不会去实现这种功能。
使用ROPC和SPA

SPA作为一种常见的客户端的程序，一般不保存secret，所以少了很大一部分的安全保护。如果你要在客户端保存secret，这是一种妥协策略。

ROPC本身是允许refresh token的，所以需要在server端禁用offline_access，不让SPA来刷新token。每次都要获取新的token。

最后的一些想法

我只有在两种情况会同意使用ROPC。

在不需要浏览器的情况下，比如apple tv。
需要把一个2000年之前的老应用迁移过来。但其实我也曾经在一个vb.net的webform集成了IdentityServer，所以，我可能也不是很建议你使用。

最后说两点。

如果你的应用是基于浏览器的客户端应用，试试 Implicit。
如果你的是原生应用，试试Authorization Code。

我的博客即将搬运同步至腾讯云+社区，邀请大家一同入驻：https://cloud.tencent.com/developer/support-plan?invite_code=17r6m6mx83vk4