1 前言
1.1 背景
前端为手机APP应用，采用HTTPS+RESTful协议通过互联网与后端API服务器集群进行通信，接口认证基于OAuth2协议。
简单的架构图如下所示：
1.2 痛点
虽然API接口传输采用了HTTPS进行加密传输，但是一部分接口仍旧存在重放攻击（Replay Attack）的风险，下文分析了多种不同的防御重放攻击的方案。
2 基于APP端维护的Key进行认证
2.1 采用随机数进行签名认证
APP维护一个OAuth2 Server的用户名/密码，APP每次在进行注册/登录接口请求之前，先从API Server获取一个请求ID和一个随机数。然后APP使用这个随机数作为密钥，对APP的OAuth2用户名/密码进行HmacSHA256哈希计算，并用base64编码生成数字签名，然后再将用户注册/登录参数以及请求ID、数字签名一并传递到API Server，API Server根据这些信息来判断请求是否合法。
优点：没有使用时间戳，不需要用户手机和API Server的时钟同步；
缺点：API Server需要额外维护APP请求ID以及随机数，并且APP需要多调用一次获取请求ID和随机数的接口。
2.2 采用数字签名+时间戳进行认证
APP维护一个OAuth2 Server的用户名/密码，APP每次在进行注册/登录接口请求之前，使用APP的OAuth2密码对请求进行HmacSHA256哈希计算，并用base64编码生成数字签名，然后再将用户注册/登录参数以及数字签名、时间戳（用于判断请求是否过期，一般设置为15分钟过期）一并传递到API Server，API Server根据这些信息来判断请求是否合法。
优点：API Server不需要额外维护APP请求ID以及随机数；APP无需在注册/登录前多调用一次获取请求ID和随机数的接口；
缺点：需要保证用户手机和API Server的时钟同步；在请求时间未过期的时间内仍旧存在重放攻击的可能性。
2.3 APP先进行OAuth2认证，然后传递access_token
APP维护一个OAuth2 Server的用户名/密码，APP每次在进行注册/登录接口请求之前，先调用OAuth2 Server接口进行认证并获取access_token，然后再将用户注册/登录参数以及该access_token一并传递到API Server，API Server配置注册/登录接口需要进行OAuth2认证。
优点：实现简单，只需很小改动即可实现；
缺点：APP需要多进行一次OAuth2接口调用；如果APP的access_token泄漏，仍旧存在重放攻击的可能性（其它使用access_token进行认证的接口也同样存在这个问题）。
3 无需APP端维护Key的方式进行认证
3.1 时间戳方式
“时戳”──代表当前时刻的数。
基本思想──A接收一个消息当且仅当其包含一个对A而言足够接近当前时刻的时戳。
原理──重放的时戳将相对远离当前时刻。
时钟要求──通信各方的计算机时钟保持同步。
处理方式──设置大小适当的时间窗（间隔），越大越能包容网络传输延时，越小越能防重放攻击。
适用性──用于非连接性的对话。在连接情形下双方时钟若偶然出现不同步，则正确的信息可能会被误判为重放信息而丢弃，而错误的重放信息可能会当作最新信息而接收。
3.2 序列号递增方式
通信双方通过消息中的序列号来判断消息的新鲜性。
要求通信双方必须事先协商一个初始序列号，并协商递增方法。
针对APP的实现方式：每个APP生成一个唯一编码代表该APP，登录的时候将该编码以及协商的序列号一起发送到服务端，服务接收到消息之后进行检查，只有符合条件的请求才会被认为合法，其他请求被认为不合法。
关键点：APP编码生成算法只能由APP和服务端知晓；序列号递增方式也只能由APP和服务端知晓；可考虑初始序列号跟APP编码关联产生。
3.3 提问应答方式
“现时”──与当前事件有关的一次性随机数N（互不重复即可）。
基本做法──期望从B获得消息的A 事先发给B一个现时N，并要求B应答的消息中包含N或f(N)，f是A、B预先约定的简单函数。
原理──A通过B回复的N或f(N)与自己发出是否一致来判定本次消息是不是重放的。
时钟要求──无。
适用性──用于连接性的对话。
本文出自 “烟花易冷” 博客，请务必保留此出处http://yuanhuan.blog.51cto.com/3367116/1441298