不要使用Resource Owner Password Credentials
不要使用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。查看我的文章保护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