如何保證API接口安全？ 一、摘要 二、方案介紹 2.1、token方案 2.2、接口簽名 二、程序實踐 2.1、token方案 2.2、接口簽名 三、小結

一、摘要

在實際的業務開發過程中，我們常常會碰到需要與第三方互聯網公司進行技術對接，例如支付寶支付對接、微信支付對接、高德地圖查詢對接等等服務，如果你是一個創業型互聯網，大部分可能都是對接別的公司api接口。

當你的公司體量上來了時候，這個時候可能有一些公司開始找你進行技術對接了，轉變成由你來提供api接口，那這個時候，我們應該如何設計並保證API接口安全呢？

二、方案介紹

最常用的方案，主要有兩種：

• token方案
• 接口簽名

2.1、token方案

其中 token 方案，是一種在web端使用最廣的接口鑑權方案，我記得在之前寫過一篇《手把手教你，使用JWT實現單點登錄》的文章，裏面介紹的比較詳細，有興趣的朋友可以看一下，沒了解的也沒關係，我們在此簡單的介紹一下 token 方案。

從上圖，我們可以很清晰的看到，token 方案的實現主要有以下幾個步驟：

• 1、用戶登錄成功之後，服務端會給用戶生成一個唯一有效的憑證，這個有效值被稱爲token
• 2、當用戶每次請求其他的業務接口時，需要在請求頭部帶上token
• 3、服務端接受到客戶端業務接口請求時，會驗證token的合法性，如果不合法會提示給客戶端；如果合法，纔會進入業務處理流程。

在實際使用過程中，當用戶登錄成功之後，生成的token存放在redis中時是有時效的，一般設置爲2個小時，過了2個小時之後會自動失效，這個時候我們就需要重新登錄，然後再次獲取有效token。

token方案，是目前業務類型的項目當中使用最廣的方案，而且實用性非常高，可以很有效的防止黑客們進行抓包、爬取數據。

但是 token 方案也有一些缺點！最明顯的就是與第三方公司進行接口對接的時候，當你的接口請求量非常大，這個時候 token 突然失效了，會有大量的接口請求失敗。

這個我深有體會，我記得在很早的時候，跟一家中、大型互聯網公司進行聯調的時候，他們提供給我的接口對接方案就是token方案，當時我司的流量高峯期時候，請求他們的接口大量報錯，原因就是因爲token失效了，當token失效時，我們會調用他們刷新token接口，刷新完成之後，在token失效與重新刷新token這個時間間隔期間，就會出現大量的請求失敗的日誌，因此在實際API對接過程中，我不推薦大家採用 token方案。

2.2、接口簽名

接口簽名，顧名思義，就是通過一些簽名規則對參數進行簽名，然後把簽名的信息放入請求頭部，服務端收到客戶端請求之後，同樣的只需要按照已定的規則生產對應的簽名串與客戶端的簽名信息進行對比，如果一致，就進入業務處理流程；如果不通過，就提示簽名驗證失敗。

在接口簽名方案中，主要有四個核心參數：

• 1、appid表示應用ID，其中與之匹配的還有appsecret，表示應用密鑰，用於數據的簽名加密，不同的對接項目分配不同的appid和appsecret，保證數據安全
• 2、timestamp 表示時間戳，當請求的時間戳與服務器中的時間戳，差值在5分鐘之內，屬於有效請求，不在此範圍內，屬於無效請求
• 3、nonce 表示臨時流水號，用於防止重複提交驗證
• 4、signature 表示簽名字段，用於判斷接口請求是否有效。

其中籤名的生成規則，分兩個步驟：

• 第一步：對請求參數進行一次md5加密簽名

//步驟一
String 參數1 = 請求方式 + 請求URL相對地址 + 請求Body字符串;
String 參數1加密結果= md5(參數1)

• 第二步：對第一步簽名結果，再進行一次md5加密簽名

//步驟二
String 參數2 = appsecret + timestamp + nonce + 參數1加密結果;
String 參數2加密結果= md5(參數2)

參數2加密結果，就是我們要的最終簽名串。

接口簽名方案，尤其是在接口請求量很大的情況下，依然很穩定。

換句話說，你可以將接口簽名看作成對token方案的一種補充。

但是如果想把接口簽名方案，推廣到前後端對接，答案是：不適合。

因爲簽名計算非常複雜，其次，就是容易泄漏appsecret！

說了這麼多，下面我們就一起來用程序實踐一下吧！

二、程序實踐

2.1、token方案

就像上文所說，token方案重點在於，當用戶登錄成功之後，我們只需要生成好對應的token，然後將其返回給前端，在下次請求業務接口的時候，需要把token帶上。

具體的實踐，也可以分兩種：

• 第一種：採用uuid生成token，然後將token存放在redis中，同時設置有效期2哥小時
• 第二種：採用JWT工具來生成token，這種token是可以跨平臺的，天然支持分佈式，其實本質也是採用時間戳+密鑰，來生成一個token。

下面，我們介紹的是第二種實現方式。

首先，編寫一個jwt 工具。

public class JwtTokenUtil {
    //定義token返回頭部
    public static final String AUTH_HEADER_KEY = "Authorization";
    //token前綴
    public static final String TOKEN_PREFIX = "Bearer ";
    //簽名密鑰
    public static final String KEY = "q3t6w9z$C&F)J@NcQfTjWnZr4u7x";
    //有效期默認爲 2hour
    public static final Long EXPIRATION_TIME = 1000L*60*60*2;
    /**
     * 創建TOKEN
     * @param content
     * @return
     */
    public static String createToken(String content){
        return TOKEN_PREFIX + JWT.create()
                .withSubject(content)
                .withExpiresAt(new Date(System.currentTimeMillis() + EXPIRATION_TIME))
                .sign(Algorithm.HMAC512(KEY));
    }
    /**
     * 驗證token
     * @param token
     */
    public static String verifyToken(String token) throws Exception {
        try {
            return JWT.require(Algorithm.HMAC512(KEY))
                    .build()
                    .verify(token.replace(TOKEN_PREFIX, ""))
                    .getSubject();
        } catch (TokenExpiredException e){
            throw new Exception("token已失效，請重新登錄",e);
        } catch (JWTVerificationException e) {
            throw new Exception("token驗證失敗！",e);
        }
    }
}

接着，我們在登錄的時候，生成一個token，然後返回給客戶端。

@RequestMapping(value = "/login", method = RequestMethod.POST, produces = {"application/json;charset=UTF-8"})
public UserVo login(@RequestBody UserDto userDto, HttpServletResponse response){
    //...參數合法性驗證
    //從數據庫獲取用戶信息
    User dbUser = userService.selectByUserNo(userDto.getUserNo);
    //....用戶、密碼驗證
    //創建token，並將token放在響應頭
    UserToken userToken = new UserToken();
    BeanUtils.copyProperties(dbUser,userToken);
    String token = JwtTokenUtil.createToken(JSONObject.toJSONString(userToken));
    response.setHeader(JwtTokenUtil.AUTH_HEADER_KEY, token);
    //定義返回結果
    UserVo result = new UserVo();
    BeanUtils.copyProperties(dbUser,result);
    return result;
}

最後，編寫一個統一攔截器，用於驗證客戶端傳入的token是否有效。

@Slf4j
public class AuthenticationInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 從http請求頭中取出token
        final String token = request.getHeader(JwtTokenUtil.AUTH_HEADER_KEY);
        //如果不是映射到方法，直接通過
        if(!(handler instanceof HandlerMethod)){
            return true;
        }
        //如果是方法探測，直接通過
        if (HttpMethod.OPTIONS.equals(request.getMethod())) {
            response.setStatus(HttpServletResponse.SC_OK);
            return true;
        }
        //如果方法有JwtIgnore註解，直接通過
        HandlerMethod handlerMethod = (HandlerMethod) handler;
        Method method=handlerMethod.getMethod();
        if (method.isAnnotationPresent(JwtIgnore.class)) {
            JwtIgnore jwtIgnore = method.getAnnotation(JwtIgnore.class);
            if(jwtIgnore.value()){
                return true;
            }
        }
        LocalAssert.isStringEmpty(token, "token爲空，鑑權失敗！");
        //驗證，並獲取token內部信息
        String userToken = JwtTokenUtil.verifyToken(token);
        //將token放入本地緩存
        WebContextUtil.setUserToken(userToken);
        return true;
    }
    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        //方法結束後，移除緩存的token
        WebContextUtil.removeUserToken();
    }
}

在生成token的時候，我們可以將一些基本的用戶信息，例如用戶ID、用戶姓名，存入token中，這樣當token鑑權通過之後，我們只需要通過解析裏面的信息，即可獲取對應的用戶ID，可以省下去數據庫查詢一些基本信息的操作。

同時，使用的過程中，儘量不要存放敏感信息，因爲很容易被黑客解析！

2.2、接口簽名

同樣的思路，站在服務端驗證的角度，我們可以先編寫一個簽名攔截器，驗證客戶端傳入的參數是否合法，只要有一項不合法，就提示錯誤。

具體代碼實踐如下：

public class SignInterceptor implements HandlerInterceptor {

    @Autowired
    private AppSecretService appSecretService;

    @Autowired
    private RedisUtil redisUtil;

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
            throws Exception {
        //appId驗證
        final String appId = request.getHeader("appid");
        if(StringUtils.isEmpty(appId)){
            throw new CommonException("appid不能爲空");
        }
        String appSecret = appSecretService.getAppSecretByAppId(appId);
        if(StringUtils.isEmpty(appSecret)){
            throw new CommonException("appid不合法");
        }
        //時間戳驗證
        final String timestamp = request.getHeader("timestamp");
        if(StringUtils.isEmpty(timestamp)){
            throw new CommonException("timestamp不能爲空");
        }
        //大於5分鐘，非法請求
        long diff = System.currentTimeMillis() - Long.parseLong(timestamp);
        if(Math.abs(diff) > 1000 * 60 * 5){
            throw new CommonException("timestamp已過期");
        }
        //臨時流水號，防止重複提交
        final String nonce = request.getHeader("nonce");
        if(StringUtils.isEmpty(nonce)){
            throw new CommonException("nonce不能爲空");
        }
        //驗證簽名
        final String signature = request.getHeader("signature");
        if(StringUtils.isEmpty(nonce)){
            throw new CommonException("signature不能爲空");
        }
        final String method = request.getMethod();
        final String url = request.getRequestURI();
        final String body = StreamUtils.copyToString(request.getInputStream(), Charset.forName("UTF-8"));
        String signResult = SignUtil.getSignature(method, url, body, timestamp, nonce, appSecret);
        if(!signature.equals(signResult)){
            throw new CommonException("簽名驗證失敗");
        }
        //檢查是否重複請求
        String key = appId + "_" + timestamp + "_" + nonce;
        if(redisUtil.exist(key)){
            throw new CommonException("當前請求正在處理，請不要重複提交");
        }
        //設置5分鐘
        redisUtil.save(key, signResult, 5*60);
        request.setAttribute("reidsKey",key);
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)
            throws Exception {
        //請求處理完畢之後，移除緩存
        String value = request.getAttribute("reidsKey");
        if(!StringUtils.isEmpty(value)){
            redisUtil.remove(value);
        }
    }

}

簽名工具類SignUtil：

public class SignUtil {

    /**
     * 簽名計算
     * @param method
     * @param url
     * @param body
     * @param timestamp
     * @param nonce
     * @param appSecret
     * @return
     */
    public static String getSignature(String method, String url, String body, String timestamp, String nonce, String appSecret){
        //第一層簽名
        String requestStr1 = method + url + body + appSecret;
        String signResult1 = DigestUtils.md5Hex(requestStr1);
        //第二層簽名
        String requestStr2 = appSecret + timestamp + nonce + signResult1;
        String signResult2 = DigestUtils.md5Hex(requestStr2);
        return signResult2;
    }
}

簽名計算，可以換成hamc方式進行計算，思路大致一樣。

三、小結

上面介紹的token和接口簽名方案，對外都可以對提供的接口起到保護作用，防止別人篡改請求，或者模擬請求。

但是缺少對數據自身的安全保護，即請求的參數和返回的數據都是有可能被別人攔截獲取的，而這些數據又是明文的，所以只要被攔截，就能獲得相應的業務數據。

對於這種情況，推薦大家對請求參數和返回參數進行加密處理，例如RSA、AES等加密工具。

同時，在生產環境，採用https方式進行傳輸，可以起到很好的安全保護作用！