目录

• • 需求
  • 需求分析简单过程
  • 总结
  • 参考文章

需求

一个简单的需求分析，对接口添加一个鉴权

1. 从简单到困难，先给出最简单方案，在依次添加约束条件，对其进行优化

需求分析简单过程

一、增加 appID和秘钥，客户段每次访问，带上用户名和密码，服务器解析appid和密码，和自己存储的对比
● 不安全、明文传输

二、通过加密算法加密 （sha），用户名和算法，服务器反解密
● 不安全，会被未认证系统轻易截获，访问我们接口，重放攻击

三、利用开源框架思想，oath ，将url、appid、密码拼接一起，生成token， 客户端拼接ull+参数 appid 和token ，服务器，获取appid，利用同样算法拼接生成token ，对比客户端
● 也可能被截获重放工具，难度提高了一点，token是固定的，很容易获取

四、增加个随机变量，比如数据戳， 每次接口生成token不一样， 四个参数加密，服务器 验证当前时间戳和客户端时间戳是否在一定的时间窗口内，没有超过1分钟，没有过期，
● 也不安全，可以重放攻击，但是难度提高了，没有绝对安全，权衡开发成本、安全

五、appid和秘钥怎么存储，可以开放接口，比如数据库、本地配置文件、配置中心、redis中等

六、最终需求
● 调用方进行接口请求的时候，将 URL、AppID、密码、时间戳拼接在一起，通过加密算法生成 token，并且将 token、AppID、时间戳拼接在 URL 中，一并发送到微服务端。
● 微服务端在接收到调用方的接口请求之后，从请求中拆解出 token、AppID、时间戳。
● 微服务端首先检查传递过来的时间戳跟当前时间，是否在 token 失效时间窗口内。如果已经超过失效时间，那就算接口调用鉴权失败，拒绝接口调用请求。
● 如果 token 验证没有过期失效，微服务端再从自己的存储中，取出 AppID 对应的密码，通过同样的 token 生成算法，生成另外一个 token，与调用方传递过来的 token 进行匹配；如果一致，则鉴权成功，允许接口调用，否则就拒绝接口调用。

总结

一句话：使用进化算法的思想，提出一个MVP（最小可行性产品），逐步迭代改进。 拿到这个需求，假设我们不了解接口鉴权，需求又不明确，我会我自己如下问题：

1.什么叫接口鉴权？搞清基本概念
2.接口鉴权最佳实践是什么？技术调研
3.appid和secret key从哪里来？用户自己申请还是我们授权？用户申请是以什么方式申请（网页还是邮件？申请的网页有人做了么？）追问下去。
4.appid secretkey存储在什么地方呢？数据存储
5.用户如何使用？需要为用户提供接口鉴权使用手册和文档，及示例代码。写用户手册，文档。
6.这个功能如何测试？提前想好如何测试
7.接口鉴权功能何时上线？估计工期 8.鉴权成功或失败返回码和信息定义？约定返回结果

参考文章

https://www.jianshu.com/p/7ba48cf8d23d