金融软件网站建设公司排名,免费物业网站模板,网站方案设计与论证,做亚马逊一个月挣10万1 需求
1.1 需求背景
为了保证接口调用的安全性#xff0c;我们希望设计实现一个接口调用鉴权功能#xff0c;只有经过认证之后的系统才能调用我们的接口#xff0c;没有认证过的系统调用我们的接口会被拒绝。
2 需求分析
2.1 基础分析
对于如何做鉴权这样一个问题我们希望设计实现一个接口调用鉴权功能只有经过认证之后的系统才能调用我们的接口没有认证过的系统调用我们的接口会被拒绝。
2 需求分析
2.1 基础分析
对于如何做鉴权这样一个问题最简单的解决方案就是通过用户名加密码来做认证。我们给每个允许访问我们服务的调用方派发一个应用名或者叫应用 ID、AppID和一个对应的密码或者叫秘钥。
调用方每次进行接口请求的时候都携带自己的 AppID 和密码。微服务在接收到接口调用请求之后会解析出 AppID 和密码跟存储在微服务端的 AppID 和密码进行比对。如果一致说明认证成功则允许接口调用请求否则就拒绝接口调用请求。
2.2 分析优化
每次都要明文传输密码密码很容易被截获是不安全的。那如果我们借助加密算法比如 SHA对密码进行加密之后再传递到微服务端验证是不是就可以了呢
实际上这样也是不安全的因为加密之后的密码及 AppID照样可以被未认证系统或者说黑客截获未认证系统可以携带这个加密之后的密码以及对应的 AppID伪装成已认证系统来访问我们的接口。这就是典型的“重放攻击”。
对于刚刚这个问题我们可以借助 OAuth 的验证思路来解决。调用方将请求接口的 URL 跟 AppID、密码拼接在一起然后进行加密生成一个 token。调用方在进行接口请求的的时候将这个 token 及 AppID随 URL 一块传递给微服务端。微服务端接收到这些数据之后根据 AppID 从数据库中取出对应的密码并通过同样的 token 生成算法生成另外一个 token。用这个新生成的 token 跟调用方传递过来的 token 对比。如果一致则允许接口调用请求否则就拒绝接口调用请求。 2.3 继续优化
不过这样的设计仍然存在重放攻击的风险还是不够安全。每个 URL 拼接上 AppID、密码生成的 token 都是固定的。未认证系统截获 URL、token 和 AppID 之后还是可以通过重放攻击的方式伪装成认证系统调用这个 URL 对应的接口。
为了解决这个问题我们可以进一步优化 token 生成算法引入一个随机变量让每次接口请求生成的 token 都不一样。我们可以选择时间戳作为随机变量。原来的 token 是对 URL、AppID、密码三者进行加密生成的现在我们将 URL、AppID、密码、时间戳四者进行加密来生成 token。调用方在进行接口请求的时候将 token、AppID、时间戳随 URL 一并传递给微服务端。
微服务端在收到这些数据之后会验证当前时间戳跟传递过来的时间戳是否在一定的时间窗口内比如一分钟。如果超过一分钟则判定 token 过期拒绝接口请求。如果没有超过一分钟则说明 token 没有过期就再通过同样的 token 生成算法在服务端生成新的 token与调用方传递过来的 token 比对看是否一致。如果一致则允许接口调用请求否则就拒绝接口调用请求。 2.4 还是继续优化
不过你可能会说这样还是不够安全啊。未认证系统还是可以在这一分钟的 token 失效窗口内通过截获请求、重放请求来调用我们的接口啊
你说得没错。不过攻与防之间本来就没有绝对的安全。我们能做的就是尽量提高攻击的成本。这个方案虽然还有漏洞但是实现起来足够简单而且不会过度影响接口本身的性能比如响应时间。所以权衡安全性、开发成本、对系统性能的影响这个方案算是比较折中、比较合理的了。
实际上还有一个细节我们没有考虑到那就是如何在微服务端存储每个授权调用方的 AppID 和密码。当然这个问题并不难。最容易想到的方案就是存储到数据库里比如 MySQL。不过开发像鉴权这样的非业务功能最好不要与具体的第三方系统有过度的耦合。
针对 AppID 和密码的存储我们最好能灵活地支持各种不同的存储方式比如 ZooKeeper、本地配置文件、自研配置中心、MySQL、Redis 等。我们不一定针对每种存储方式都去做代码实现但起码要留有扩展点保证系统有足够的灵活性和扩展性能够在我们切换存储方式的时候尽可能地减少代码的改动。
3 开发
3.1 划分职责进而识别出有哪些类
功能列表 可以粗略地得到三个核心的类AuthToken、Url、CredentialStorage。
3.2 定义类及其属性和方法
3.2.1 AuthToken 3.2.2 Url 3.2.3 CredentialStorage 3.3 定义类与类之间的交互关系 3.4 将类组装起来并提供执行入口
