我们的接口需要提供给外部第三方系统去调用，那么在做开放接口安全管理的时候先要想明白几点，为什么要做安全，有哪些地方要做安全？
解决方式：
（1）优化方式一：数据加密
调用方将调用方身份信息和密码通过明文的方式传递过来，这个过程会被第三方截取获取到appKey和password（这里的appKey就相当于appid或clientid，password就相当于密钥secret），第三方可以根据获取到的信息伪装成已认证的调用方去调用服务方服务获取接口信息，对服务方服务的稳定性、安全性造成威胁。这就是“重放攻击”。
解决办法：
对数据进行加密。
调用方将调用的接口名 + 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值进行比较，相同，则允许访问；不相同，则拒绝访问。
（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：相同，允许访问；不相同；拒绝访问；
（3）代码实战
上述方式得到的功能点列表如下：
(1)把 URL、appKey、密码、时间戳拼接为一个字符串；
(2)对字符串通过加密算法加密生成 token；
(3)将 token、appKey、时间戳拼接到 URL 中，形成新的 URL；
(4)解析 URL，得到 token、appKey、时间戳等信息；
(5)从存储中取出 appKey 和对应的密码；
(6)根据时间戳判断 token 是否过期失效；
(7)验证两个 token 是否匹配；
应用鉴权：对方在调用我方服务某个接口的时候，需要将对方的用户标识，如appKey，传过来。我方看此appKey是否有授权调用的权限，没有直接返回失败；有授权即可正常返回结果；
接口鉴权：更细粒度的鉴权，在应用鉴权通过之后，还需要对某个接口进行鉴权。如：团队A想要调用订单服务，我们只想开发订单查询接口的权限，而涉及到订单退款等操作类的接口可拒绝对方访问。常见的接口鉴权有RPC接口之间的调用鉴权和HTTP接口调用鉴权
参考：
方式1：注解+AOP实现：appId和secret+token+时间戳（重要）
接口鉴权实践_接口鉴权怎么做_不务正业的攻城狮的博客-****博客
（WebMvcConfigurer 拦截做鉴权）
SpringBoot之接口鉴权_springboot接口鉴权_风口上的吱吱鼠的博客-****博客
方式二：公钥私钥做法
太强了！看看别人设计的安全好用的OpenApi！-****博客（重要）