系统服务化构建-两方OAuth

鉴于微博,QQ,微信等开发平台的影响,互联网界的工程师都知道OAuth协议,对Token 存储用户信息的机制有所了解,却很少有人提及两方OAuth这个概念。

两方OAuth

说到OAuth协议,潜意识里都会想到涉及认证,客户,和服务器,进而是认证服务器,客户端应用和资源服务器三方。

现在通用的OAuth协议是OAuth2.0,是一个互联网开放授权协议,用于规范资源服务器,客户端应用,授权服务器三者的职责,实现客户端应用在不直接获取到普通用户的用户名和密码的前提下,访问用户的私有资源。

在实际应用开发过程中,我们的应用复杂性没有达到一定规模时,应用程序只涉及到客户端APP和服务器端中心云服务的认证和业务处理。我们可以对OAuth2.0协议进行简化,演变为两方OAuth。

系统服务化构建-两方OAuth_第1张图片

上图[Auth-history.png]是几个服务器客户端验证的阶段。

OAuth 协议更多的可以理解为是一个宽泛的协议,在工程应用方面只关注规范,不要求细节。
最初的OAuth协议是服务器根据HTTP 协议头的Authorization 字段验证客户端身份。而如今逐渐演变成使用Token 的方式标记客户端身份,存储用户状态信息,至于Token如何生成,在HTTP 协议中如何传输,并没有过多硬性要求。

消费者APP

在OAuth协议体系中,消费者是指开发者开发的APP,这里的APP 更是一个广义的概念,不局限在安卓和iOS应用这两种类型。PC网站,移动端WebView也被认为是APP

服务端,各种云平台如何识别这些应用,借助于应用编号和应用密钥机制,应用编号就是APP_ID,或者APP_KEY,用于唯一识别应用。密钥就是APP_SERCRET,用于请求签名等安全算法的入参,和服务器端验证的凭据。

APP_KEY和APP_SERCRET的分配和管理是实现两方OAuth的第一步

读到这里,或许你有疑问了,上文说到的不同APP,无非是安卓,iOS,WebView,我们何不定义不同的枚举来标明不同的客户端,甚至可以使用User-Agent判断。

1 PC,2 安卓 3 iOS 4 微信

这样的分类可以解决吗,答案是很难。

实际上这是两个概念,从操作系统的角度划分更多的是一种数据来源渠道的概念,而APP_KEY的本质属性是接入云端平台的开发者应用标记。

Token 生命周期

以下是一个简版的Token生命周期模型

分配

Token由客户端发起,服务器云端负责分配,典型的场景,在用户登录成功后分配,一定有效期内过期,支持每次请求不一致,token滑动过期机制。默认30分钟失效。

生成规则

用户标记key: userid+应用编号。md5(userid+盐钥+时间戳) 盐值固定。生成规则可以根据项目个性化调整,Token值不可逆。

存储

服务器端 key value形式存储到redis中,key为token,value为加密值
客户端 Token,按需存储在本地,后续接口调用时使用

失效

过期时间内失效,如初始分配60分钟,那60分钟后自动生效。
退出时,需要调用接口,删除Token。

这里会引出一个思考

退出功能需要网络支持吗?

这个问题的缘由是我发现有些工程师,退出功能是这么做的,页面跳转,清除本地Token。

Token代表的是用户状态,这种状态代表的是客户端与服务端的一种关联关系,退出功能是切断这种关联。

HTTP 是无状态的,单纯的做请求响应,而业务必须是有状态的,否则业务无法流转和推进,这种状态交给Token负责,二者是如何关联的。是Token设计中需要考量的。

一个相对完整的Token落地机制是实现两方OAuth的第二步

签名算法

签名(Sign)用于保证数据的真实性和完整性,从时效,合法性,频率几个维度处理。

对所有待签名参数按照字段名的ASCII码从小到大排序(字典序)后,使用URL键值对的格式(即key1=value​1&key2=value2…)拼接成字符串string1。这里需要注意的是所有参数名均为小写字符,最后加&secret=app_secret; 对string1作签名算法,字段名和字段值都采用原始值不进行URL转义。具体签名算法为sign = md5(string)。
除登录外所有接口,由服务端决定开启或者关闭签名验证。业界叫验签。

签名就用到了APP_SECRET

系统服务化构建-两方OAuth_第2张图片

设计要点

采用前后端分离,将接口参数分为系统级别参数和业务级别参数。
系统级参数主要包括app_key,timestamp,token,os_type,sign,主要置于HTTP 请求头位置。
业务参数基于业务需求,采用POST 或者GET方法按需传递。

检测请求超时

通过客户端时间戳timestamp,来确定真正的客户端发起时间。
服务器端检测时间差,客户端请求时间与服务器时间的差值与超时时间做对比。例如,我们可以约定时间差大于5分钟间隔的请求为无效请求,或者超时请求。

识别终端

使用App-Key的方式识别应用终端,企业内部不同的应用,由云端服务统一管理。

场景1

进行个性化配置 ,来自于微信公众号的登录用户的过期时长设置为一天,而来自于PC官网的用户的登录过期时长设置为一周。
场景2

公司某个产品线的普通版和定制版的区分,使用App-Key,对功能的简易复杂度,收费模式做梯度设置。

场景3

应用于SASS应用识别,多租户数据隔离,在数据库对应用数据做隔离。进而为相关的运营数据分析提供支持。

其它设计规约

1 后台配置关闭启用开关,开发阶段可以关闭验证,建议开启。
2 启用验证后,前端需要有公共方法计算请求签名。后台需要增加安全验证模块验证请求合法性,负责登录过期失效检测,参数完整性和权限验证。
3 安全方面关注安全弹性,安全验证级别通过timestamp, sign, token参数,三个维度配合,逐层升级。通过增加验证条件和复杂性增强安全级别。安全级别做到合理即可,没有一概而论。

总结

以上给出了一套基于两方OAuth方式的云端,客户端服务设计模型。在应用服务不复杂,业务场景允许的前提下,使用两个OAuth方式,伴随着业务发展,可以逐步演化为基于三方身份的OAuth协议工程实现。
Token机制和签名机制也可以 独立分层,与业务应用分离,演化为网关系统。
这样的设计符合架构领域的简单,演化原则,是一种很实惠的应用架构方案。


系统服务化构建-两方OAuth_第3张图片

你可能感兴趣的:(php,服务架构,oauth,开放平台)