oAuth与SSO是一回事吗

一、 背景

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

二、 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.商户请求把自身会员数据授权给ERP，ERP生成会员页面的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.一般三方应用入驻平台都会有线下的资质审核，例如身份证、营业执照等等，所谓跑得了和尚跑不了庙；审核通过后会给三方派发appid与appsecret，每次请求都需要带上这两个参数，后者需要保存在三方后端服务器里，谁都不能告诉

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
业务场景	开放平台、企业能力透出	大型网站用户鉴权
参与角色	有内部也有外部	纯内部角色
系统功能	授权为主，鉴权为辅	鉴权
鉴权对象	三方应用为主，用户为辅	用户
风险点	用户信息安全	用户伪造登录
思想概括	主客权限的隔离 敏感信息高低频分离	同源策略的分离与收敛