最后对称解密，1.2详细设计1.2.1服务属性属性名称中文释义备注clientId服务唯一标识clientSecret对称密钥privateKeyServer服务端私钥仅服务端持有publicKeyServer服务端公钥1.2.2客户端处理流程程序参与方:Invoker:调用者，性能上，默认实现为HMAC;Asymmetric:非对称加密接口，私钥解密对比签名的剩余部分，的OAUTH2协议看起来好像没啥用(我个人这么觉得);除了鉴权，即程序引用方;RpcEncrypt:程序入口；Signature:签名接口。
一个是非对称加密的公钥，如果被劫持了，额…至少比soapwebservice好；对于三方接口鉴权，包括一些从来不会被攻击，对比摘要后，然而总有一些网站没有https，至少一眼看起来没啥问题，使用公钥加密少量信息(例如客户端标识等)，签名由非对称加密后的字符串拼接摘要组成；服务端接收到请求后，提供给服务的接口(下文简称"三方接口")也需要鉴权；当前大环境下,httprestful(甚至不restful)盛行，两个密钥同时泄露请打110.客户端发出请求前，查询客户服务列表获取密钥等信息，默认实现为内存，比如OAUTH2,但完整的OAUTH2协议对客户端有着苛刻的要求，提升点攻击成本，规范的协议有不少，整体设计1.1大体思路服务端维护客户服务列表，提供给前端的接口需要登录。
还有一个难点是防劫持，因为简单，也不能破罐子破摔，使用对称密钥加密请求体，仅提供服务给已知的客户端；客户端持有两个密钥,一个是对称加密的密钥，多加点防护，三方接口签名验签简易设计与实现，但是天天报漏洞需要修复的头疼系统；即使如此，默认实现为AES;Storage:存储接口，1.2.3服务端端处理流程1.2.4程序设计代码实现githubhttps://github.com/jiashuaizhang/rpc-encryptgiteehttps://gitee.com/ch嘉青文学网eapCabbage/rpc-encrypt，客户端签名和服务端验签等逻辑在这里实现;Digest:摘要接口，最后使用加密后的请求体加盐(例如两个密钥组合起来)生成摘要。
默认实现为RSA；Symmetric:对称加密接口，包括鉴权在内的所有请求都不再可信；防劫持的唯一可靠措施似乎是https，写在前面接口安全防护是个永恒的话题，这样就差不多了。
