我们知道，做为一个web系统，少不了要调用别的系统的接口或者是提供接口供别的系统调用。从接口的使用范围也可以分为对内和对外两种，对内的接口主要限于一些我们内部系统的调用，多是通过内网进行调用，往往不用考虑太复杂的鉴权操作。但是，对于对外的接口，我们就不得不重视这个问题，外部接口没有做鉴权的操作就直接发布到互联网无疑是
而这不仅有暴露数据的风险，同时还有数据被篡改的风险，严重的甚至是影响到系统的正常运转！
接下来，我将结合实际代码，分享一套接口鉴权实践方法。

方案一 appId和secret

接口鉴权？那还不简单，给每个应用下发一个appId和secret，接口调用方每次携带appId和secret调用接口。但是这样真的安全吗？每次调用都要传输密码，很容易被截获。

方案二 appId和secret+token

调用方根据接口的URL和appId、secret组合在一起，然后加密生成一个token，服务端接收到对应请求之后按照同样的方法生成一个token，然后校验token的 正确性。但是这种方式每个url拼接上appId、secret生成的token是一样的，未授权系统截获后还是可以通过重放的方式，伪装成认证系统，调用这个接口。

方案三 appId和secret+token+时间戳

同方案二类似，token的生成过程中在加入时间戳，校验token正确性之前先校验时间戳是否在一定时间窗口内（比如说1分钟），如果超过一分钟，直接拒绝请求，通过后再校验token。

方案四 appId+token+时间戳

相对方案二，方案三的方法相对已经有很大提升了（同样参数不能无限制调用）,但是仔细一想，还是有问题，攻击者截获请求以后，还是可以在一定时间窗口内通过重放攻击的方式发送请求。那么，有没有终极大招呢？

实际上，攻防之间没有绝对的安全，我们能做的是尽量提高攻击者的成本。这个方案虽然还有漏洞，但是实现起来简单，而且不会过度影响接口性能。权衡安全性、开发成本以及对系统性能的影响，这个方案算是比较合理的一个了。接下来，我将通过java代码一步一步实现这个鉴权功能。

首先，抽出一个AuthToken.java，定义了生成AuthToken以及校验token是否过期的方法