接口鉴权功能的实现

一、背景

随着系统的发展，单体应用逐渐演化成微服务架构。系统微服务化之后，若干个微服务之间会有调用。同个部门内实现的服务会被内部调用，一般风险是可控的。但是如果服务提供给别的部门使用之后，在不了解对方的使用场景，接口调用QPS等，如果对方接口调用量过大，会影响整个使用该服务的调用方，且对接口的安全性也会有风险。在这种情况下，每个微服务都需要对调用者进行鉴权。

基本的鉴权维度有：

• 应用鉴权：对方在调用我方服务某个接口的时候，需要将对方的用户标识，如appKey，传过来。我方看此appKey是否有授权调用的权限，没有直接返回失败；有授权即可正常返回结果；
• 接口鉴权：更细粒度的鉴权，在应用鉴权通过之后，还需要对某个接口进行鉴权。如：团队A想要调用订单服务，我们只想开发订单查询接口的权限，而涉及到订单退款等操作类的接口可拒绝对方访问。常见的接口鉴权有RPC接口之间的调用鉴权和HTTP接口调用鉴权。

二、需求分析

1、基本实现方案

首先，我们能想到的最基本的实现方案：

• 调用方申请访问权限，服务方授权之后会生成调用方对应的密码，存储到DB/缓存等具有存储功能的组件中，appKey <—> password
• 调用方在调用接口时，需要将appKey和password一起当做参数传过来；
• 服务方在收到请求之后取出请求中的参数appKey和密码password，根据apppKey从DB/缓存等获取对应密码，判断服务方存储的密码与对方传过来的密码是否一致，不一致则拒绝访问。

2、重放攻击

上述流程是最简单的实现，但是存在重放攻击的风险。

重放攻击是指：

重放攻击(Replay Attacks)又称重播攻击、回放攻击，是指攻击者发送一个目的主机已接收过的包，来达到欺骗系统的目的，主要用于身份认证过程，破坏认证的正确性。重放攻击可以由发起者，也可以由拦截并重发该数据的敌方进行。攻击者利用网络监听或者其他方式盗取认证凭据，之后再把它重新发给认证服务器。重放攻击在任何网络通过程中都可能发生，是计算机世界黑客常用的攻击方式之一。

注：来源于百度百科

通俗点解释：攻击者利用网络监听或其他方式截取A发送给B的报文，并把由A加密的报文发送给B，使B误以为入侵者就是A，然后主机B向伪装成A的攻击者发送应当发送给A的报文。

3、优化方式

（1）优化方式一：数据加密

调用方将调用方身份信息和密码通过明文的方式传递过来，这个过程会被第三方截取获取到appKey和password，第三方可以根据获取到的信息伪装成已认证的调用方去调用服务方服务获取接口信息，对服务方服务的稳定性、安全性造成威胁。这就是“重放攻击”。

解决办法：

对数据进行加密。

• 调用方将调用的接口名 + appKey + 密码 拼在一起，通过加密算法对其加密生成一个token值，然后再将token值拼接在原调用的url后发送至服务方，如：http://localhost:8080/user?getUserInfo?userId=1234&appKey=abc&token=dasadjij21oijiooodsadaodjaosnd

• 服务方接收到调用方发送的请求后，解析获取到appKey、token值，根据appKey从服务方存储地获取到对应password值，然后用同样的加密算法生成服务端的token值：token_s，用token_s与调用方的token值进行比较，相同，则允许访问；不相同，则拒绝访问。

（图片来源：极客时间https://time.geekbang.org/column/article/171760）

（2）优化方式二：数据加密 + 随机数

上述方式对于安全性要求不高的内部系统已经绰绰有余。但是这种设计仍然存在重放攻击的风险：由于生成的token值是固定的，攻击者可以花费一定的时间去破解。所以需要继续优化token生成算法，生成动态token来避免这种风险。

解决办法：

为了生成动态的token，引入一个随机数，在加密的时候也对随机数进行加密，这样每次生成的token就是动态变化的。一般使用时间戳作为随机数，使用时间戳作为随机数的好处是：接收方解析到时间戳后还可以验证token是否过期，比如时间戳是一年之前对应的时间戳，自然不允许访问；

• 调用方对 url + appKey + 密码 + 时间戳 进行加密，生成一动态token，拼接在url后，同时拼接上时间戳，发送给服务方；

• 服务方接收到请求之后，

  • 首先解析出 appKey、密码、时间戳、token；

  • 再校验时间戳是否在时间窗口内，比如1小时；校验不通过则认为token过期直接拒绝访问，通过进入下一步；

  • 然后根据appKey去查询对应的passwrod_s，使用相同的加密算法对

    url + appKey + passwrod_s + 时间戳 进行加密生成新token_s，比较

    token 和 token_s：相同，允许访问；不相同；拒绝访问；

示意图如下：

（图片来源：极客时间https://time.geekbang.org/column/article/171760）

4、时序图

上述时序图如下：

三、代码实战

上述方式得到的功能点列表如下：

• (1)把 URL、appKey、密码、时间戳拼接为一个字符串；
• (2)对字符串通过加密算法加密生成 token；
• (3)将 token、appKey、时间戳拼接到 URL 中，形成新的 URL；
• (4)解析 URL，得到 token、appKey、时间戳等信息；
• (5)从存储中取出 appKey 和对应的密码；
• (6)根据时间戳判断 token 是否过期失效；
• (7)验证两个 token 是否匹配；

经过分析可知，设计3个功能：

• Url操作相关，包括Url拼接参数和解析Url；
• Token操作相关，包括token生成、判断token过期、判断token是否匹配；
• appKey存储和查询；

所以按领域模型划分，总共有3个模型，对应3个类，如下：

（1）Url不仅包括HTTP接口url请求，也有RPC接口请求，因此抽象封装成ApiRequest类：

（2）Token类设计：

AuthToken

(3)AppKey查询，为了抽象，提供接口：

（4）定义好领域模型的设计之后，需要将这些类组装起来并提供入口：

public interface ApiAuthencator {
    
    
    void auth(String url);
    void auth(ApiRequest apiRequest);
}

（5）测试

为了更好的测试效果，提供了InvokerController类，来模拟客户端调用时token生成、拼接url、触发服务端鉴权等动作。

完整代码见：完整代码

---

参考：极客时间《设计模式之美》