必备的三种接口鉴权方式
最近在做 L5 【核心】级别数据的相关接口，全部接口交互必须进行鉴权及加密，保障数据安全。凑着这次机会，简单介绍几种常用的接口鉴权方式，希望对你有所帮助！
注：均在 HTTPS TTL 的基础上
鉴权方式的分类
从互联网诞生以来，数据/接口鉴权的方式千千万万。可以根据应用场景及使用方式上简单划分为两类：嵌入类【SDK】、接口类【API】，当然其本质都是相同的。
SDK
在 SDK 场景下，常规做法是使用 token。Client 端 和 Server 端，约定 AppID、AppSecrit 及动态密钥。
动态密钥：适度时间粒度变更，往往 C\S 端会保持长链接或者心跳检测时，进行数据的同步及更新。
Token 鉴权
- 在 Client 启动的时候，Server 就会按照约定的这些信息生成加密字段下发给 Client ；然后，Client 每次进行交互时都会带上这个参数做身份鉴权。
- Server 端收到 Clinet 上传的数据后，会与之前约束下生成的密钥进行对比校验，无误方可进行后续交互；反之，判定为非法或异常请求。
当前一些大厂牌或者安全性要求高的场景，会在此基础上将 交互过程中作为比对的密钥字段进行 AES 加密传输。这样保证及时数据在网络传输过程中出现拦截，也无法被识别分析，或者使得识别分析成本极高，阻止相关黑产或非法操作。
更近一步而言，在银行或涉及钱、个人信息等场景下，即使这样的接口成功通过 token 鉴权，但还会进行 个人确认额外的鉴权。比如，手机验证码、图形勾选…等等。
API
在 API 接口场景下，双方或者多方之间不会存在长期链接，或者额外建立周期 token 同步机制成本过高，意味着使用 SDK token 常规的鉴权不太切合。
Sign 鉴权
现在业界常规的做法是进行 sign 校验或者叫做 接口加盐。其实是一种交互方之间约定一静态密钥，在数据传输时，将参数以 k=v 格式组织 + 倒/顺序 产出字符串之后，把 静态密钥 追加至末尾，md5 之后产出一加密串。
每次进行交互时，接收方会按照接收到的参数按照相同的方式进行产出密钥，然后依据此字段进行比对，来核验数据是否被篡改、及请求是否非法、异常。
当然在此基础上，也可以进行另外的改造。
AES 变形
拿去即用：AES 对称加密中的 ECB实现。
这里介绍两种方式，一种是网站或者 H5 比较常用，将请求整个进行 AES 加密。呈现出来就是，网页地址栏里就一串类似乱码的密钥，安全性相对较高。
数据接受方将用约定的密钥进行密文反解，获得明文参数。但这种方式存在问题。
- 当传输数据量较大时，双方在进行加/解密的复杂度上升，对服务 CPU/性能 会有明显的影响。
所以，这里抛出第二种方式，”组合拳“。
我们将缩小加密数据的规模，只将核心数据进行加密，非核心数据将明文传输进行 Sign 校验。
数据接受方，先将核心数据解密，因为缺少核心数据，服务往往无法提供；之后，进行全部参数的 Sign 校验。这样一套 “组合拳” 可以保障接口及数据的安全，当然是一定程度上的安全。
Token + Sign 变形
这里在介绍一种变形方式，是属于 Token 和 Sign 的组合变形。交互双方会约定一 “长串“ 密钥，对种非常长的密钥。在这个密钥上，会有一套动态策略生成 Seed，也叫做截断点。
数据进行交互时，会同时按照动态策略采用 ”长串“ 密钥的某一个部分作为 Sign 的密钥，进行 Sign 校验方式组织进行传输。
动态测量往往会与时间进行耦合，毕竟时间是个不可多得的自增序数据。
核心数据的位置偏移
介绍到这里，突然又想起一种方式，这种方式是和位置移动有关。比如，传输的参数是 “abc"，传输的时候就变成了 “cde" ，位置偏移了三位。
当然这只是个例子，具体的偏移与适用的场景和实现有关。
…
当然，鉴权的方式很多种，这里只是简单给大家提供个常规的思路。后续有详细的实现或者方案会在博文补充。