接口之间传递inputstream_设计模式之美（十一）如何对接口鉴权功能开发做面向对象分析？...

王争《设计模式之美》笔记

案例介绍和难点剖析

需求：为了保证接口调用的安全性，我们希望设计实现一个接口调用鉴权功能，只有经过认证之后的系统才能调用我们的接口，没有认证过的系统调用我们的接口会被拒绝。

一时间无从下手的两点原因。

1. 需求不明确

需求过于模糊、笼统，不够具体、细化，离落地到设计、编码还有一定的距离

2.缺少锻炼

鉴权作为一个跟具体业务无关的功能，完全可以把它开发成一个独立的框架，集成到很多业务系统中。而作为被很多系统复用的通用框架，比起普通的业务代码，我们对框架的代码质量要求要更高。

对案例进行需求分析

针对鉴权这个功能的开发，我们该如何做需求分析？

1. 第一轮基础分析

对于如何做鉴权这样一个问题，最简单的解决方案就是，通过用户名加密码来做认证。我们给每个允许访问我们服务的调用方，派发一个应用名(或者叫应用 ID、AppID)和一个对 应的密码(或者叫秘钥)。调用方每次进行接口请求的时候，都携带自己的 AppID 和密 码。微服务在接收到接口调用请求之后，会解析出 AppID 和密码，跟存储在微服务端的AppID 和密码进行比对。如果一致，说明认证成功，则允许接口调用请求;否则，就拒绝接口调用请求。

2. 第二轮分析优化

不过，这样的验证方式，每次都要明文传输密码。密码很容易被截获，是不安全的。那如果我们借助加密算法(比如 SHA)，对密码进行加密之后，再传递到微服务端验证，是不是就可以了呢?实际上，这样也是不安全的，因为加密之后的密码及 AppID，照样可以被未 认证系统(或者说黑客)截获，未认证系统可以携带这个加密之后的密码以及对应的 AppID，伪装成已认证系统来访问我们的接口。这就是典型的“重放攻击”。

提出问题，然后再解决问题，是一个非常好的迭代优化方法。对于刚刚这个问题，我们可以借助 OAuth 的验证思路来解决。调用方将请求接口的 URL 跟 AppID、密码拼接在一起，然后进行加密，生成一个token。调用方在进行接口请求的的时候，将这个token 及 AppID，随URL一块传递给微服端。微服务端接收到这些数据之后，根据 AppID 从数据库中取出对应的密码，并通过同样的 token生成算法，生成另外一个 token。用这个新生成的 token 跟调用方传递过来的token 对比。如果一致，则允许接口调用请求;否则，就拒绝接口调用请求。

这个方案稍微有点复杂，我画了一张示例图，来帮你理解整个流程。

3.第三轮分析优化

不过，这样的设计仍然存在重放攻击的风险，还是不够安全。每个 URL 拼接上 AppID、密 码生成的 token 都是固定的。未认证系统截获 URL、token 和 AppID 之后，还是可以通过重放攻击的方式，伪装成认证系统，调用这个URL对应的接口。

为了解决这个问题，我们可以进一步优化 token 生成算法，引入一个随机变量，让每次接口请求生成的 token都不一样。我们可以选择时间戳作为随机变量。原来的token是对 URL、AppID、密码三者进行加密生成的，现在我们将URL、AppID、密码、时间戳四者 进行加密来生成token。调用方在进行接口请求的时候，将 token、AppID、时间戳，随 URL 一并传递给微服务端。

微服务端在收到这些数据之后，会验证当前时间戳跟传递过来的时间戳，是否在一定的时间窗口内(比如一分钟)。如果超过一分钟，则判定token过期，拒绝接口请求。如果没有超过一分钟，则说明 token 没有过期，就再通过同样的token 生成算法，在服务端生成新的token，与调用方传递过来的 token比对，看是否一致。如果一致，则允许接口调用请求;否则，就拒绝接口调用请求。

4.第四轮分析优化

不过，你可能会说，这样还是不够安全啊。未认证系统还是可以在这一分钟的 token 失效窗口内，通过截获请求、重放请求，来调用我们的接口啊!

你说得没错。不过，攻与防之间，本来就没有绝对的安全。我们能做的就是，尽量提高攻击的成本。这个方案虽然还有漏洞，但是实现起来足够简单，而且不会过度影响接口本身的性能(比如响应时间)。所以，权衡安全性、开发成本、对系统性能的影响，这个方案算是比较折中、比较合理的了。

5. 最终确定需求

(1)调用方进行接口请求的时候，将 URL、AppID、密码、时间戳拼接在一起，通过加密算 法生成 token，并且将 token、AppID、时间戳拼接在 URL 中，一并发送到微服务端。

(2) URL、AppID、密码、时间戳拼接在一起，通过加密算法生成 token，并且将 tokenAppID、时间戳拼接在 URL 中，一并发送到微服务端。

(3)微服务端在接收到调用方的接口请求之后，从请求中拆解出 token、AppID、时间戳。

(4)微服务端首先检查传递过来的时间戳跟当前时间，是否在token失效时间窗口内。如果已经超过失效时间，那就算接口调用鉴权失败，拒绝接口调用请求。

(5)如果 token 验证没有过期失效，微服务端再从自己的存储中，取出 AppID 对应的密 码，通过同样的 token生成算法，生成另外一个token，与调用方传递过来的token 进行匹配;如果一致，则鉴权成功，允许接口调用，否则就拒绝接口调用。

这就是我们需求分析的整个思考过程，从最粗糙、最模糊的需求开始，通过“提出问题 - 解决问题”的方式，循序渐进地进行优化，最后得到一个足够清晰、可落地的需求描述。

重点回顾

(1)针对框架、类库、组件等非业务系统的开发，其中一个比较大的难点就是，需求一般都比较抽象、模糊，需要你自己去挖掘，做合理取舍、权衡、假设，把抽象的问题具象化，最终产生清晰的、可落地的需求定义。需求定义是否清晰、合理，直接影响了后续的设计、编码实现是否顺畅。所以，作为程序员，你一定不要只关心设计与实现，前期的需求分析同等重要。

(2)需求分析的过程实际上是一个不断迭代优化的过程。我们不要试图一下就能给出一个完美的解决方案，而是先给出一个粗糙的、基础的方案，有一个迭代的基础，然后再慢慢优化，这样一个思考过程能让我们摆脱无从下手的窘境。

课堂讨论-我的思考

除了工作中我们会遇到需求不明确的开发任务，实际上，在面试中，我们也经常遇到一些开放性的设计问题，对于这类问题，你是如何解答的?有哪些好的经验可以分享给大家呢?

• 如果概念不清楚或业务内容不清楚，先清楚
• 需要用的什么技术，心里大概有个数，不太熟悉的在看下
• 梳理该需求连接的上下游。
• 开始针对该需求具体分析

遇到这种情况，你是怎么做的呢，欢迎分享。

参考：https://time.geekbang.org/column/intro/250?code=gLit0LpsKZQ6vOVqS1htGOSAKYLCYeMuklw2dwajH-4%3D