一般来说APP提供的服务都是基于 HTTP 协议的，云端对客户端发过来的每一个请求，都进行了身份鉴别（Authentication）和访问授权（Authorization）的严格检查。
在封装的SDK（对外输出）中，为每一个应用准备了三个身份鉴别需要的标识：
- appId：这是一个应用的全局唯一标识，类似于我们个人的身份证号码。
- appKey：用于判断来自该应用客户端的请求是否合法的验证序号。
- masterKey：也是一种 appKey，只是使用它来进行请求的时候 ，云端会忽视所有的访问权限控制（因为它拥有超级权限，用它来发起操作，类似于在 Linux 系统中的 root 在进行操作。），因此禁止在客户端或不信任的环境下使用，以免泄漏。
在使用 SDK 或者直接请求 REST API 的时候，都需要在 HTTP Header 中提供 appId 和 appKey 信息：appId 用来标识是哪一个应用发起的请求，appKey 则用来对请求的合法性进行鉴权。
+
网络世界中总有一些别有用心的人存在，appId 和 appKey 在这里是明文传输的，尽管我们做了很多努力，但还是难保不会泄漏。所以，为了避免这种风险，我们又采用了一种更安全的鉴权方式： 在 HTTP Header 中不再直接填写 appKey，而用一个「签名字符串」代替。 签名字符串在客户端计算，由 appKey（或者 masterKey） 加上请求发起时的时间（精确到毫秒），再对它们进行 MD5 签名之后得到的字符串。云端收到这样的请求之后，根据 appId 可以找到内部保存的 appKey，然后经过同样的散列函数计算出签名，比较后如果签名不匹配或者请求已经超时，则认为是一个非法请求而直接丢弃，如果是一个合法请求，则再进入下面的访问授权检查流程。
+
如此一来，网络传输过程中，我们可以做到不再暴露任何 appKey 的信息，但是对于原生的 iOS、Android 应用，或者 Web 站点来说，黑客还可以通过反编译等手段，获知到代码中在初始化 SDK 时设定的 appId 和 appKey。所以我们不能假设 appKey 不会泄漏，而应该使用下一节介绍的访问控制列表来加强数据的安全性。