安全认证系列之-API 接口应该如何设计？如何保证安全？如何签名？如何防重？

前言

目前公司在做一套关于XX商店在线迁移，之前别人公司给了一份接口文档，里面涉及到了签名，也就是做接口安全验证用的，因为之前做一汽项目也涉及到了https以及sign签名认证，于是觉得十分有必要梳理这块知识，可能只是个小功能点，但是使用场景确十分普遍，可以解决工作中的实际痛点，例如做秒杀活动时，避免接口冲刷。

在实际的业务中，难免会跟第三方系统进行数据的交互与传递，那么如何保证数据在传输过程中的安全呢（防窃取）？除了https的协议之外，能不能加上通用的一套算法以及规范来保证传输的安全性呢？

下面我们就来讨论下常用的一些API设计的安全方法，可能不一定是最好的，有更牛逼的实现方式，但是这篇是我自己的经验分享.

一.TOKEN介绍

Token：访问令牌access token, 用于接口中, 用于标识接口调用者的身份、凭证，减少用户名和密码的传输次数。一般情况下客户端(接口调用方)需要先向服务器端申请一个接口调用的账号，服务器会给出一个appId和一个key, key用于参数签名使用，注意key保存到客户端，需要做一些安全处理，防止泄露。

Token的值一般是UUID，服务端生成Token后需要将token做为key，将一些和token关联的信息作为value保存到缓存服务器中(redis)，当一个请求过来后，服务器就去缓存服务器中查询这个Token是否存在，存在则调用接口，不存在返回接口错误，一般通过拦截器或者过滤器来实现，Token分为两种：

• API Token(接口令牌): 用于访问不需要用户登录的接口，如登录、注册、一些基本数据的获取等。获取接口令牌需要拿appId、timestamp和sign来换，sign=加密(timestamp+key)
  个人理解：就是接口令牌不需要携带用户信息，只需要校验签名，签名校验正确则就可以访问接口了。前提是客户端、服务端协定了一套加密算法，并指定了加密秘钥。同时服务端、客户端都同时掌握这个加密秘钥，以及加密算法。
  1.客户端携带appId、timestamp和signA访问接口。
  2.服务端收到请求，根据协定的key 由key+appId+timestamp生成加密签名signB。
  3.服务端将服务端生成的signB 与 客户端传递过来的 signA进行对比，如果相等则可以继续访问接口。如果不行则不能继续访问接口，服务端返回错误信提示，例如：“验签失败”

• USER Token(用户令牌): 用于访问需要用户登录之后的接口，如：获取我的基本信息、保存、修改、删除等操作。获取用户令牌需要拿用户名和密码来换。
  1.客户端使用用户名跟密码请求登录
  2.服务端收到请求，去验证用户名与密码
  3.验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
  4.客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里
  5.客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
  6.服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据。

关于Token的时效性：token可以是一次性的、也可以在一段时间范围内是有效的，具体使用哪种看业务需要。

一般情况下接口最好使用https协议，如果使用http协议，Token机制只是一种减少被黑的可能性，其实只能防君子不能防小人。

一般token、timestamp和sign 三个参数会在接口中会同时作为参数传递，每个参数都有各自的用途。同时存在的时候，就是我们上面说的两层认证都有，即接口认证、用户认证。这样会更加安全。

二.timestamp 简介

timestamp: 时间戳，是客户端调用接口时对应的当前时间戳，时间戳用于防止DoS攻击。

当黑客劫持了请求的url去DoS攻击，每次调用接口时接口都会判断服务器当前系统时间和接口中传的的timestamp的差值，如果这个差值超过某个设置的时间(假如5分钟)，那么这个请求将被拦截掉，如果在设置的超时时间范围内，是不能阻止DoS攻击的。timestamp机制只能减轻DoS攻击的时间，缩短攻击时间。如果黑客修改了时间戳的值可通过sign签名机制来处理。

三.sign 简介

nonce：随机值，是客户端随机生成的值，作为参数传递过来，随机值的目的是增加sign签名的多变性。随机值一般是数字和字母的组合，6位长度，随机值的组成和长度没有固定规则。

sign: 一般用于参数签名，防止参数被非法篡改，最常见的是修改金额等重要敏感参数， sign的值一般是将所有非空参数按照升续排序然后+token+key+timestamp+nonce(随机数)拼接在一起，然后使用某种加密算法进行加密，作为接口中的一个参数sign来传递，也可以将sign放到请求头中。

接口在网络传输过程中如果被黑客挟持，并修改其中的参数值，然后再继续调用接口，虽然参数的值被修改了，但是因为黑客不知道sign是如何计算出来的，不知道sign都有哪些值构成，不知道以怎样的顺序拼接在一起的，最重要的是不知道签名字符串中的key是什么，所以黑客可以篡改参数的值，但没法修改sign的值，当服务器调用接口前会按照sign的规则重新计算出sign的值然后和接口传递的sign参数的值做比较，如果相等表示参数值没有被篡改，如果不等，表示参数被非法篡改了，就不执行接口了。

四.防止重复提交

其实对我最吸引的就是这块内容了，因为前面博主在研究秒杀系统如何防止恶意的重复提交增加系统负担，增加出错成本。秒杀只是一个场景，一些对外暴露的API也同样适合。但是彻底理解这个概念还需要花点时间自己整理一下思路。

对于一些重要的操作需要防止客户端重复提交的(如非幂等性重要操作)，具体办法是当请求第一次提交时将sign作为key保存到redis，并设置超时时间，超时时间和Timestamp中设置的差值相同。因为sign得算法是根据服务端 以及 客户端协定好的，所以当用户携带sign到服务器时，我们将这个sign存储到缓存

当同一个请求第二次访问时会先检测redis是否存在该sign，如果存在则证明重复提交了，接口就不再继续调用了。如果sign在缓存服务器中因过期时间到了，而被删除了，此时当这个url再次请求服务器时，因token的过期时间和sign的过期时间一直，sign过期也意味着token过期，那样同样的url再访问服务器会因token错误会被拦截掉，这就是为什么sign和token的过期时间要保持一致的原因。拒绝重复调用机制确保URL被别人截获了也无法使用（如抓取数据）。

对于哪些接口需要防止重复提交可以自定义个注解来标记。

注意：所有的安全措施都用上的话有时候难免太过复杂，在实际项目中需要根据自身情况作出裁剪，比如可以只使用签名机制就可以保证信息不会被篡改，或者定向提供服务的时候只用Token机制就可以了。如何裁剪，全看项目实际情况和对接口安全性的要求。

五.使用流程

1.接口调用方(客户端)向接口提供方(服务器)申请接口调用账号，申请成功后，接口提供方会给接口调用方一个appId和一个key参数

2.客户端携带参数appId、timestamp、sign去调用服务器端的API token，其中sign=加密(appId + timestamp + key)

3.客户端拿着api_token 去访问不需要登录就能访问的接口

4.当访问用户需要登录的接口时，客户端跳转到登录页面，通过用户名和密码调用登录接口，登录接口会返回一个usertoken, 客户端拿着usertoken 去访问需要登录才能访问的接口

sign的作用是防止参数被篡改，客户端调用服务端时需要传递sign参数，服务器响应客户端时也可以返回一个sign用于客户度校验返回的值是否被非法篡改了。客户端传的sign和服务器端响应的sign算法可能会不同。

六.ThreadLocal

ThreadLocal是线程内的全局上下文。就是在单个线程中，方法之间共享的内存，每个方法都可以从该上下文中获取值和修改值。

实际案例：

在调用api时都会传一个token参数，通常会写一个拦截器来校验token是否合法，我们可以通过token找到对应的用户信息(User)，如果token合法，然后将用户信息存储到ThreadLocal中，这样无论是在controller、service、dao的哪一层都能访问到该用户的信息。作用类似于Web中的request作用域。

传统方式我们要在方法中访问某个变量，可以通过传参的形式往方法中传参，如果多个方法都要使用那么每个方法都要传参；如果使用ThreadLocal所有方法就不需要传该参数了，每个方法都可以通过ThreadLocal来访问该值。

ThreadLocalUtil.set("key", value); 保存值
T value = ThreadLocalUtil.get("key"); 获取值

public class ThreadLocalUtil<T> {
    private static final ThreadLocal<Map<String, Object>> threadLocal = new ThreadLocal() {
        @Override
        protected Map<String, Object> initialValue() {
return new HashMap<>(4);
        }
    };

    public static Map<String, Object> getThreadLocal(){
return threadLocal.get();
    }

    public static <T> T get(String key) {
Map map = (Map)threadLocal.get();
return (T)map.get(key);
    }

    public static <T> T get(String key,T defaultValue) {
Map map = (Map)threadLocal.get();
return (T)map.get(key) == null ? defaultValue : (T)map.get(key);
    }

    public static void set(String key, Object value) {
Map map = (Map)threadLocal.get();
        map.put(key, value);
    }

    public static void set(Map<String, Object> keyValueMap) {
Map map = (Map)threadLocal.get();
        map.putAll(keyValueMap);
    }

    public static void remove() {
        threadLocal.remove();
    }

    public static <T> Map<String,T> fetchVarsByPrefix(String prefix) {
Map<String,T> vars = new HashMap<>();
if( prefix == null ){
return vars;
        }
Map map = (Map)threadLocal.get();
Set<Map.Entry> set = map.entrySet();

for( Map.Entry entry : set){
Object key = entry.getKey();
if( key instanceof String ){
if( ((String) key).startsWith(prefix) ){
                    vars.put((String)key,(T)entry.getValue());
                }
            }
        }
return vars;
    }

    public static <T> T remove(String key) {
Map map = (Map)threadLocal.get();
return (T)map.remove(key);
    }

    public static void clear(String prefix) {
if( prefix == null ){
return;
        }
Map map = (Map)threadLocal.get();
Set<Map.Entry> set = map.entrySet();
        List<String> removeKeys = new ArrayList<>();

for( Map.Entry entry : set ){
Object key = entry.getKey();
if( key instanceof String ){
if( ((String) key).startsWith(prefix) ){
                    removeKeys.add((String)key);
                }
            }
        }
for( String key : removeKeys ){
            map.remove(key);
        }
    }
}

总结:这个是目前第三方数据接口交互过程中常用的一些参数与使用示例，希望对大家有点帮助。

当然如果为了保证更加的安全，可以加上RSA,RSA2，AES等等加密方式，保证了数据的更加的安全，但是唯一的缺点是加密与解密比较耗费CPU的资源。