引子
对于业务的发展阶段，不同的人对0到100的定义差距很大。上图是我认知里的阶段划分。和很多人的认知相比，我认为的1不是系统搭建起来可用，而是系统已经获得了一定的认可，具备持续运营的条件；下一阶段是高速发展期，系统复杂性增加，业务量指数级增长，甚至应该是在行业处于领先地位才能叫做10；在100的阶段是做到了行业第一。毕竟不是第一怎么敢说给自己打100分呢？100+就像是小学生常规题满分之后的附加题一样，是要有超纲性的，需要在维持行业领头羊基础上孵化出新业务并取得了一定成绩的，比如谷歌，依托于行业翘楚的搜索引擎，孵化出Google Maps、Gmail。
在越往后的阶段，对安全上的要求也会越来越高。对接口安全来说，常考虑的是两个方面，一个是鉴权，一个是加密。鉴权要求高的场景下，常用的是两种体系：一种是OAuth体系，一种是JWT体系。这两种体系根据不同的安全等级，会使用其他安全技术来配合。比如OAuth2.0+openid connect。各种标准的RFC文档可在这个网站找到：https://datatracker.ietf.org/doc/html/rfc6749。我周末读了OAuth2.0和JWT两个文档，共花了5个小时的时间。
不管是哪种体系，鉴权实际上包含上图流程中的1、传输加密；2、身份认证；3、鉴权三个部分。今天咱们以JWT为例来说明这个体系怎样和其他鉴权方式配合使用。
JWT体系举例
开放平台的权限控制一般来说常使用CBAC。
基于声明的访问控制（Claim-Based Access Control, CBAC）：
CBAC 模型强调用户、资源和权限的声明性描述。用户、资源和权限都有一组声明（即属性），系统通过比较这些声明来决定用户是否有权访问资源。CBAC 模型提供了更加灵活和可扩展的权限管理，可以与其他安全模型（如 OAuth、SAML 等）集成。
假设一个开放平台提供以下三个等级的控制声明：
API-Key：API Key是一种简单的接口鉴权方式，平台分配一个API Key给合作方。合作方通过将API Key放在请求头或URL参数中，服务端验证API Key的合法性。API Key易于实现，但安全性较低，容易被攻击者盗取。
需要签名的鉴权方式一般使用的就是JWT。
SON Web Tokens (JWT)：JWT是一个开放标准（RFC 7519），它定义了一种简洁、自包含的方式用于通信双方之间以JSON对象的形式安全地传输信息。JWT常用于身份验证和信息交换场景。
实现JWT的步骤：
1、有效期声明
在JWT规范中，明确规定参数中需要带有效期的声明。比如以下参数timestamp字段就是这个声明的一种实现。
2、Payload
将参数列表排列成一个 string。用 & 分隔每个参数。对于上述参数，签名 payload 如下所示：
symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2×tamp=1668481559918&recvWindow=5000br3、计算签名
将签名有效负载编码为 ASCII 数据并使用带有 SHA-256 hash 函数的 RSASSA-PKCS1-v1_5 算法对 payload 进行签名。
这句话信息量比较大，用图来表示：
计算签名分三步：
第一步：将签名有效负载编码为 ASCII 数据
第二步：将待签名的 M 进行 Hash，JWT规范中建议使用HMAC SHA-256散列算法，得到的字符串，咱们用H代表
第三步：将 H 进行 RSA 私钥加密。RSASSA-PKCS1-v1_5是一种RSA算法实现。
第四步：JWT又分为JWS和JWE，它们的区别白话来讲JWS需要再将得到的字符串做一次base64，而JWE不做这一步。咱们通常都会使用JWS。
具体实现步骤可参考JWT的RFC规范文档实现部分：https://datatracker.ietf.org/doc/html/rfc7519#section-8。
JWT体系总结
JWT鉴权体系和Oauth体系一样，集成了很多身份认证、加密的技术，如：api key、HMAC、RSA。这些本身都可以单独使用，也可以组合使用。
JWT为什么要组合这些技术呢？
JWT 的优点包括它们的大小小、传输速度快，以及它们是自包含的，这意味着在 JWT 本身就包含了所有需要的信息，减少了需要查询数据库的次数。然而，它们也有安全性问题，例如如果密钥被泄露，那么签名的 JWT 可能会被篡改。因此，使用 JWT 时应该采取适当的安全措施，例如使用上面介绍的强密码学算法和确保密钥的安全存储。
