API 授权与验证机制

概览

传统 API 而言，授权与验证机制一直是被高度重视的安全问题之一，API 安全一直是被开发者们所讨论。SUBMAIL API 在设计之初便已将 API 安全问题融入到我们的 DNA 。

SUBMAIL 有两种验证方式：密匙明文验证模式和数字签名验证模式，选择一种适合你生产环境的验证机制。

密匙明文验证模式

明文的密匙验证模式，这种验证方式在集成接入过程中非常高效。

要使用密匙明文验证模式，请在 signature 参数 中提交你的应用密匙。

使用密匙明文验证模式时，请忽略 timestamp 和 sign_type 参数

数字签名验证模式

数字签名验证模式，适用于安全要求较高的应用。

数字签名方法与规则

1. 将所有提交的参数升序排列：仅单次提交的参数，不包括 signature 字段升序（A-Z）排列
2. 创建签名字符串：以"key=value" + "&"（连接符）+ "key=value" 的方式连接所有参数。此签名字符串类似与 HTTP GET/POST 请求时的字符串。
3. 创建签名：在创建的字符串前后加上 APPID 和 APPKEY 拼接签名字符串（以 PHP 为例：string=appid.appkey.signature.appid.appkey），然后使用 md5(string) 或 sha1(string)创建签名。

   
   

要使用数字签名验证模式，请将 sign_type 参数设为 md5 或 sha1 , 然后将 signature 参数设为你计算的签名字符串

（作为参考，此签名方法在 SUBMAIL SDK 中有完整的签名创建方法和案例）

Timestamp UNIX 时间戳

如果你使用数字签名方式，你需要在每条API 请求中加入 timestamp UNIX 时间戳，且此参数将必须被包含在签名字符串中，参与计算签名。

UNIX 时间戳 是安全 API 请求中非常重要的概念，在 API 请求或签名被创建之前，你需要从 SUBMAIL 服务器端获取 UNIX 时间戳，并确保请求 UNIX 时间戳至发送请求的过程小于6秒。