在系统开发阶段，经常会遇到需要跟第三方对接接口，亦或者是需要直接嵌入第三方子系统的形式；这时候系统与系统之间的通信验证方式，就需要我们好好琢磨琢磨了。 以下总结以下小编遇到和想到的验证方式：
方式一：
appId校验：由子系统分发可访问的appId，并记录该appId对应的系统信息。当主系统调用子系统接口时，带上appId，用于校验有效性且记录操作日志；该校验方式由于安全性较低，或者说无安全性可言，当appId泄漏后，将可以冒充身份使用接口；所以该方式常用于公共性子系统，接口开放。
方式二：
appId+appKey加密方式： 由子系统分发appId与appKey。其中appId为主系统id，appKey用于加密（不用于数据传输）。
步骤为：
1、子系统分发appId和appKey
2、主系统访问接口时，在参数中带入appId和sign（签名），并用appKey对参数进行特定的加密方式加密；例：sign=MD5(参数+appKey)
3、子系统收到参数后，根据appId找出对应的appKey，再根据规定的签名加密方式对参数签名后与sign进行匹配
方式三：
普通的账密： 有子系统分发主系统对应的账密； 主系统在调用接口时，都需要先调用一次登录子系统的接口获取对应的token；token需要具备一定的时效性，再存于缓存当中。然后子系统每个接口都需要带上token校验。
该方式的特点是有多个子系统（第三方），每个子系统都有各自的账密；而Client(客户端)与System Server(主系统)之间也有自己的账密访问方式；那么子系统的账密统一在主系统上进行管理，与Client没有任何关系。
方式四：
反向校验：与方式三相反，方式三是将账密放到主系统，由主系统向子系统发起校验（校验放在子系统中）。而该方式的校验方式为子系统向主系统发起校验（校验放在主系统中）。还有一个非常大的不同在于，该方式适用于客户端直接请求第三方的形式（在客户端中嵌入第三方子系统的接口或页面）。
根据上图可知，在特定的情况下， 系统服务器和认证服务器可以合并。该校验方式的特点就是安全，但是客户端每调用一次子系统的接口，子系统都需要向主系统发起校验一下，所以在效率上就会有所牺牲。