Chinaunix首页 | 论坛 | 博客
  • 博客访问: 180052
  • 博文数量: 19
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 1182
  • 用 户 组: 普通用户
  • 注册时间: 2013-02-20 23:47
个人简介

如果人生是一条隐含马尔科夫模型,那维特比算法告诉我已经偏离最优路线了,但如果起点是现在呢?

文章分类

全部博文(19)

文章存档

2020年(2)

2014年(3)

2013年(14)

分类: 网络与安全

2020-06-22 10:47:03

一、 背景

oAuthsso是互联网安全领域的重要概念,流程上看都是由一个集中的服务派发令牌,回调给一个或者多个应用,这些应用在实际请求时又带上这个令牌进行鉴权;实际工作中开发这两项技术系统的同学往往在不同领域,而作为接入方使用这两项技术的同学停留在外围,导致大家分不清这两项技术,甚至认为是一回事,本文旨在从业务产生背景、技术流程实现、问题挑战全方位对比,供大家理解背后的差异与相同

二、 oAuth2

随着互联网的充分竞争与发展,不免产生头部效应,即一些资源最后落到一两个平台上,举例来说社交平台基本都收敛到微信、微博上,餐饮行业的商户资源都集中到美团上,一方面这是优胜劣汰的结果,另一方面一家公司技术、产品、市场的能力往往有限,只有合作才能把事情做大;合作过程中就涉及到如何把平台用户的资源授权出去的问题,oAuth正是解决这类问题的方案:正常的登录验证关注的是平台如何验证用户的请求,而oAuth关注的是平台用户如何授权给三方,以及授权后三方代发起请求的验证

1. 需求

1.原始服务能力透出,接入三方应用封装增强,eg:会员数据开放给第三方代运营ERP

2.从平台角度看需要对三方进行审核准入,不能让营销、诈骗的应用进来,增加平台风险

3.商户维度授权,不是准入了就能看所有会员数据,只有特定商户给三方授权了,代运营ERP才能访问会员,需要给代运营ERP授权

4. 如何授权:不能让代运营ERP保存商家在平台的账号密码,即需要区分正常账号密码vs虚拟账密;反过来,授权给ERP的虚拟账密也不能让商户感知(即一人一密),即流程上:正常账密->中间账密->虚拟账密

2. 角色:

原始服务(OAuth provider):提供基础资源的服务(会员),包含了认证服务与资源服务

三方服务(OAuth Consumer):增强、封装原始服务的能力,但没有基础资源(ERP

客户(User):资源拥有者,即在原始服务里托管了基础资源,又想使用三方增强能力(商户)

3. authorization, not authentication

以下是以授权商户会员资源给第三方ERP应用的举例

1.商户请求把自身会员数据授权给ERPERP生成会员页面的url,里面携带回调url,商户在会员页面输入平台的账号密码,平台按回调url跳转回ERP页面,同时提供携带auth code

2.在跳转回ERP页面后,向后端提交auth code

3.ERP后端使用auth code向会员后端换取真正调用业务接口的access_token

4.商户使用ERP会员功能时,ERP后端使用access_token调用平台接口,平台完成鉴权,即ERP厂商有权限访问该商户的数据

4. 核心问题

上述流程有几个关键的问题

1.如何阻止恶意的三方应用入驻并套取用户信息

2.如何对保证频繁使用的access_token的安全

3.为什么第1步不直接返回access_token,而要增加一步“中间code

4.如何保持平台对于资源的掌控,防止三方应用“跳单”

应对方案:

1.一般三方应用入驻平台都会有线下的资质审核,例如身份证、营业执照等等,所谓跑得了和尚跑不了庙;审核通过后会给三方派发appidappsecret,每次请求都需要带上这两个参数,后者需要保存在三方后端服务器里,谁都不能告诉

2.在第3步返回access_token时,往往是有有效期的,同时还会返回一个无需每次资源请求都带上的refresh_token,供access_token过期后生成新token之用

3.首先authcode会在公网以及客户端环境上传输,与后端专用的access_code职责不同;另一方面access_token是三方应用与平台交互的凭证,如果要保证三方操作的不可抵赖性,就不能泄露给其他方,包括用户,更多解释详见

4.平台仅仅希望三方应用对自身的能力做扩展,对于落地数据的行为是比较敏感的,就算暴露了用户头像、昵称等信息,也是在通过接口的形式下进行访问的;除了接口上的把控,对于关键数据信息也会采取混淆措施,比如说微信的openid机制,给三方应用暴露的用户实体ID并不是可通过其他渠道(eg:手机、微信号)进行接触的ID,等于平台要想接触商户,必须通过平台这一个转换层,最大化保证平台的利益

三、 SSO

为了保证用户信息的安全,防止恶意的网站窃取数据,浏览器采取了严格的同源策略,具体的原因就不再深究了;但对于大型企业而言,问题就比较明显了,不同领域模块、业务线肯定没法统一到一个域名,这时候在多个域名切换时,是登录多次还是一次,肯定会重度影响效率以及体验,SSO单点登录就是做这个解决方案的

1. 需求

在一个域名登录后,其他域名也能免密码登录

2. 角色

1.CAS server:中心登录鉴权服务,前端提供对用户的登录页面,后端提供对业务的ticket校验

2.业务应用:企业旗下的应用,往往有不同的域名

3.浏览器:用户使用企业服务的工具

 

3. authentication, not authorization

以下是商户单点登录不同业务线系统的流程

1~2.用户打开业务1网站,网站发现用户未登录,跳转到鉴权服务域名,同时请求参数里面携带回调域名

3.用户在页面上输入账号密码,鉴权服务验证

4.验证通过后,鉴权服务session记录用户登录状态,供下一次登录时使用;同时生成凭证Service Ticket

5.用户从鉴权服务跳转回业务域名,同时携带Service Ticket

6~7.业务后端使用Service Ticket进行验证

8.验证通过后,种植session,记录用户登录状态,至此首次登录完成

9~10.用户试图登录业务2域名时,被再次跳转到鉴权服务域名,此时发现当前域名已登录,流程同第5步,从而实现免密码登录

4. 问题

1.如何阻止恶意应用冒充业务套取用户信息

2.如何防止用户伪造回调请求,完成无密码登录

应对方案:

1.目前看这种风险存在,鉴权服务可配置业务白名单,拒绝为不明域名的业务提供鉴权服务

2.只有在用户鉴权成功后才会生成合法的Service Ticket,即使用户能绕开鉴权服务的登录动作,但回到业务系统后,依然会向鉴权后端API确认登录状态

四、 对比

根据上述分析,我们尝试从多个方面对oAuth以及sso进行对比,双方有很多相同点,例如都是对需要访问资源的请求进行鉴权,组合使用前端302跳转以及后端接口完成信息交互,也有不同点,一言以蔽之,oAuth关注的是如何实现A将托管在B的资源授权给C使用,而SSO则关注如何更高效的让A登录B下的多个子系统;

 

oAuth

SSO

业务场景

开放平台、企业能力透出

大型网站用户鉴权

参与角色

有内部也有外部

纯内部角色

系统功能

授权为主,鉴权为辅

鉴权

鉴权对象

三方应用为主,用户为辅

用户

风险点

用户信息安全

用户伪造登录

思想概括

主客权限的隔离

敏感信息高低频分离

同源策略的分离与收敛

 

阅读(768) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~