安全篇-oauth2 第三方鉴权

---

theme: cyanosis

本文正在参加「金石计划 . 瓜分6万现金大奖」

# 闲聊

1、最近行情是开始回暖了吗，阿里乌冬科技也打电话找我，去年我已经面到hr面了，最近个人原因也没有去。

2、最近几周一直居家办公，特别忙，从早上坐下去就没怎么起来过，忙到晚上8-10点，噩梦级别，哈哈哈～

# 前言

最近在对接集团的鉴权功能，发现跟我们部门实现的鉴权不太一样，当时沟通的时候跟那边的同学call了几次，他说就是标准oauth2鉴权，这个词已经出现很久很久了，在我第一家公司的时候统一登录就是用oauth2规范来实现，token也是很熟悉Bearer.

说下背景，我以前没有仔细去看oauth2规范的，但是像参数签名倒是有接触过，大家可以看下之前我写的文章 动手实现对外安全的接口(改进篇)

我就会有以下几个问题：

1. 为什么我们bg的鉴权可以通过token的形式去登录，其他方案却要用到这样规范来实现呢？
2. 我之前还停留在签名加密阶段，我会有个疑问，前端把加密密钥放在代码里头，众所周知，前端代码是可以被搂出来的，也就有泄露的可能性，签名算法解决不了客户端跟服务端安全性

# 安全性-签名

签名常见就是后端调后端接口来保证安全性还有验证调用方的身份，这个是没有问题的。如果是客户端调用后端接口，如果前端采用签名方式，势必密钥要存在客户端，这就存在破译的风险，当然前端有混淆代码的功能，就是变量替代。

之前也跟蚂蚁的安全同学讨论过，就是他们会给客户端发放证书，然后各种机器对抗，防止被拿到。这个其实有点像ssl协议，就是一开始登录之后，证明你这个用户是正常的，然后发给你一个证书，证书里头有公钥，然后客户端会把共享的私钥发给服务端，然后他们就能愉快的交流了，这个跟客户端写死密钥比较靠谱的。

# 安全性-oauth2

首先我们来看下它里面的概念，资源服务器，用户，授权服务器，客户端

这个是授权码模式，用户通过第三方登录通过之后拿到授权码，然后通过授权服务器跟第三方的交互，验证授权码的准确性，然后授权服务器会给出一个token给客户端，客户端就可以通过token访问资源了。

这里解答下第一个问题，为啥不能直接采用账号密码的形式登陆然后换token，非要搞个授权码呢？

答案

面向企业内部用户的时候，我们可以保证登录上去都是我们的同学，一旦涉及到第三方就麻烦了，可能一个伪造的用户一直跟服务器在通讯。

所以它借助后端交互来保证安全性，客户端登录之后，已经代表别人的用户，第三方后端跟我们后端进行交互信息，其实我们也能get到对方用户信息，这样保证用户的安全性。

# 前端签名场景

因为我们有些业务通过userNo来查询数据的，也就是说只要你登录成功，想查询什么数据都可以，只要不断去撞库，这种是功能上设计问题导致的，本不应该出现的。

到这里就很清晰了

| 安全性方案 | 用途 | 适合场景| | --- | --- |--- | | 签名 | 签名本质是为了防止数据篡改 | 服务端之间数据通讯，比如说开放平台对接接口，因为密钥放在后端比较安全 | |oauth2|它是作为一种用户鉴权来使用，跟第三方用户体系打通| 如果是出现第三方用户、客户端其实是需要采用这种方案来解决的 |

Q:为什么说前端签名没有意义呢？

我觉得因为大多数情况，业务逻辑、处理逻辑都在后端，所以前端理论上不应该有很多骚操作的，变成了只要是用户都可以当管理员来查询数据，这是不合理的。

Q：当跨平台的时候客户端怎么通讯？

应该参考oauth2的思想，这个用户属于A平台的，那么它在你那边验证没有问题后，后端跟我这边进行通讯，然后我跟A平台一个token，这样就可以正常通讯了。或者前端通过A服务器来请求我这边的后端服务返回数据，这个才是合理的方案。

当方案很骚、比较离谱的时候，一定是用错了场景。