一个公司需要拓展业务时，内部的业务系统往往需要跟外部系统交互，比如现在用户希望在支付宝或微信上交电费，话费，转账…那么电力公司、运营商、银行就要跟支付宝和微信打通内部系统与支付宝微信系统之间的网络，提供相关api接口。
直接把API暴露到互联网上给外部系统是存在安全风险的，因此我们要先对接口调用方做一个用户鉴权，对API权限划分，如果鉴权通过则允许用户调用API。API鉴权是什么:
使用API时，对请求者身份进行验证过程
确保只有经过授权的用户或系统才能访问特定的资源或功能。
鉴权的目的是保护API安全，防止未授权的访问和潜在的安全威胁。
常见的API鉴权方式：
1.基本鉴权：通过HTTP头部传递用户名和密码的组合，通常会进行Base64编码。
2.令牌鉴权（Token-Based Authentication）：用户登录后，服务器生成一个令牌（如JWT - JSON Web Token），用户在后续请求中携带该令牌进行身份验证。
3.OAuth：开放标准，允许用户授权第三方应用访问存储在服务提供商处的资源，无需分享凭据。常用于社交媒体和第三方应用集成。
OAuth（开放授权）是一种开放标准，旨在允许用户授权第三方应用访问其在某个服务提供者上的资源，而无需分享其密码。它广泛应用于互联网中，尤其是在用户需要使用第三方服务（如社交媒体、云存储等）时。OAuth 的设计使得用户可以安全地授权应用程序访问其信息，同时保持账户凭据的安全。
1. OAuth 的基本概念
- 资源所有者（Resource Owner）：通常是用户，拥有要授权访问的资源。
- 资源服务器（Resource Server）：存储用户资源的服务器，通常通过 API 提供访问。
- 客户端（Client）：需要访问资源的应用程序或服务。
- 授权服务器（Authorization Server）：负责验证用户身份并发放访问令牌的服务器。
2. OAuth 的工作流程
OAuth 的工作流程通常包括以下几个关键步骤：
- 用户授权：
- 用户在客户端应用中请求访问受保护的资源。
- 客户端会重定向用户到授权服务器，提示用户登录并授权客户端访问其资源。
- 获取授权码：
- 用户同意后，授权服务器将用户重定向回客户端，并附带一个授权码。
- 请求访问令牌：
- 客户端使用授权码向授权服务器请求访问令牌。
- 授权服务器验证授权码和客户端身份，如果验证成功，则返回访问令牌。
- 访问资源：
- 客户端使用访问令牌向资源服务器请求访问资源。
- 资源服务器验证访问令牌，如果有效则返回请求的资源。
- 刷新令牌（可选）：
- 如果访问令牌过期，客户端可以使用刷新令牌请求新的访问令牌。
3. OAuth 的版本
- OAuth 1.0：
- 最早的 OAuth 版本，使用复杂的签名方法来验证请求，较为复杂。
- 需要为每个请求生成签名，增加了实现的复杂度。
- OAuth 2.0：
- 当前广泛使用的版本，简化了流程，易于实现。
- 使用 HTTPS 安全传输，支持多种授权方式，如授权码、隐式授权、客户端凭据等。
4. OAuth 2.0 的授权方式
OAuth 2.0 提供了多种授权方式，以适应不同类型的应用场景：
- 授权码授权（Authorization Code Grant）：
- 最常用的方式，适用于需要用户登录并返回授权码的应用。
- 适合于服务器端应用。
- 隐式授权（Implicit Grant）：
- 针对浏览器端应用（如单页应用），直接返回访问令牌。
- 不适合高安全性要求的场景，因为令牌直接暴露在 URL 中。
- 资源所有者密码凭据授权（Resource Owner Password Credentials Grant）：
- 用户直接将用户名和密码提供给客户端，适合信任的应用。
- 不推荐在不受信任的应用中使用。
- 客户端凭据授权（Client Credentials Grant）：
- 客户端直接使用其凭据（如客户端 ID 和密钥）请求访问令牌，通常用于服务间通信。
5. OAuth 的安全性
- 使用 HTTPS：确保所有通信都通过 HTTPS 进行，保护访问令牌和用户信息的安全。
- 短期访问令牌：使用短期有效的访问令牌，降低令牌泄露的风险。
- 定期更新令牌：实现刷新令牌机制，以便在访问令牌过期时能安全地请求新令牌。
- 范围限定：在请求访问令牌时，限制其访问的范围，确保应用只获得必要的权限。
4.API密钥（API Key）：用户或开发者在发起请求时提供唯一的API密钥，作为身份验证的标识。
AppID：应用的唯一标识,用来标记你的开发者账号, 是用户id, 这id 在数据库添加检索, 方便快速查找。
AppKey：公匙（相当于账号）
AppSecret：私匙（相当于密码）
app_key 和 app_secret 是一对出现的账号, 同一个 app_id 可以对应多个 app_key+app_secret,
以此来分配不同的权限,放给不同开发者. 权限配置都是跟app_key 做关联的, app_key 也要添加数据库检索, 方便快速查找。
5.签名验证（Signature Verification）：请求中加入一个数字签名，服务器根据预先约定的算法对请求验证。
签名验证（Signature Verification）是什么
2024/8/19 21:03:02
复制删除
签名验证（Signature Verification） 是一种安全性机制，用于确保数据的完整性、身份认证和不可否认性。它通常涉及对消息或数据进行数字签名，并在接收方验证签名的有效性。
1. 什么是数字签名？
数字签名是通过加密算法生成的，通常用于证明某个消息或文档的来源和完整性。它是使用发送者的私钥对数据进行加密，生成的签名与原始数据一起发送给接收方，接收方可以使用发送者的公钥来解密和验证签名。
2. 签名验证的工作流程
签名验证的流程通常包括以下几个步骤：
2.1 生成签名
- 数据哈希：发送者首先对要发送的消息（或数据）进行哈希运算，生成一个固定长度的哈希值（摘要）。
- 加密哈希：发送者使用自己的私钥对哈希值进行加密，生成数字签名。
- 发送数据：发送者将原始数据和生成的数字签名一起发送给接收方。
2.2 验证签名
- 接收数据：接收方收到原始数据和数字签名。
- 哈希计算：接收方对收到的原始数据进行哈希运算，生成哈希值。
- 解密签名：接收方使用发送者的公钥解密数字签名，得到原始的哈希值。
- 比较哈希值
：
- 如果接收方计算的哈希值与解密后的哈希值相同，签名验证通过，数据完整且来源可信。
- 如果不相同，则说明数据被篡改或签名无效。
3. 签名验证的应用场景
- 电子邮件安全：使用数字签名确保电子邮件的来源和内容未被篡改。
- 软件分发：开发者对软件二进制文件进行签名，用户可以通过验证签名确认软件来源和完整性。
- 区块链：区块链交易数据的签名验证，确保交易的有效性和不可否认性。
- 身份验证：在各种协议中（如 SSL/TLS），签名用于验证服务器和客户端的身份。
4. 常用的签名算法
一些常用的数字签名算法包括：
- RSA：一种基于大素数分解问题的公钥加密算法，广泛用于数字签名。
- DSA（数字签名算法）：由美国国家安全局设计的签名算法，基于离散对数问题。
- ECDSA（椭圆曲线数字签名算法）：基于椭圆曲线密码学的数字签名算法，相比 RSA 更加高效。
5. 签名验证的安全性
签名验证提供了多重安全性保障：
- 完整性：通过哈希算法，确保数据在传输过程中未被修改。
- 身份认证：通过公钥基础设施（PKI）确保只有合法拥有私钥的一方才能生成有效签名。
- 不可否认性：发送者无法否认已签名的消息，因为只有其私钥能够生成该签名。
token机制实现API鉴权 token令牌的机制是用来代替session的鉴权方式，现在很多api的鉴权都是通过token。
token机制是服务器端生成的一串加密串发放给客户端，客户端请求服务器端所有资源时会带上这个Token，由服务器端来校验这个token的合法性。其具有无状态、适合分布式、扩展性好、性能高和安全性好等优点。 常见的token实现有以下几种：
自定义实现token：应用开发者根据token机制原理自行实现； JWT：即Json Web Token，是一种主流的Token规范； Oauth：Oauth虽然是授权规范，但其中也用到了Token； HTTP Basic Authentication认证机制； Web API是基于HTTP协议的，而HTTP协议本身就带有认证机制。 API接口的安全措施 以上是博主总结的一些API鉴权方式。但是在调用API的过程中还需要保证数据在传输过程中的安全性、判断数据是否到达服务器以及服务器如何识别传到服务器的数据是否正确。
数据加密 数据在传输过程中是很容易被抓包的，如果直接传输，比如通过http协议，那么用户传输的数据可以被任何人获取，所以必须对数据加密。
常见的做法对关键字段加密比如用户密码直接通过md5加密；现在主流的做法是使用https协议，在http和tcp之间添加一层加密层(SSL层)，这一层负责数据的加密和解密。
现在主流的加密方式有对称加密和非对称加密。
对称加密：对称密钥在加密和解密的过程中使用的密钥是相同的，常见的对称加密算法有DES，AES，计算速度快，但是在数据传送前，发送方和接收方必须商定好秘钥，然后使双方都能保存好秘钥，如果一方的秘钥被泄露，那么也容易泄密； 非对称加密：服务端会生成一对密钥，私钥存放在服务器端，公钥可以发布给任何人使用，优点就是比起对称加密更加安全，但是加解密的速度比对称加密慢太多了，广泛使用的是RSA算法。 以上两种方式各有优缺点，而https的实现方式正好是结合了两种加密方式，整合了双方的优点，在安全和性能方面都比较好。
数据签名 数据在传输过程中经过加密，理论上就算被抓包，就无法对数据进行篡改；但是我们一般加密的部分其实只是在外网，现在很多服务在内网中都需要经过很多服务跳转，如果被攻入内网，则可以在任意节点篡改数据，所以这里的加数据签名可以防止内网中数据被篡改。
数据签名就是由发送者产生一段无法伪造的一段数字串，来保证数据在传输过程中不被篡改。
md5算法是常用的数据签名算法，其原理是将需要提交的数据通过某种方式组合成一个字符串，然后通过md5算法生成一段加密字符串，这段加密字符串就是数据包的签名。为保证安全性，最后的密钥会在客户端和服务端各备一份。
添加时间戳 经过如上的加密，加签处理，就算拿到数据也不能看到真实的数据；但是有人不关心真实的数据，而是直接拿到抓取的数据包做恶意请求，以达到自己的目的。
我们可以使用时间戳机制，在每次请求的时候加入当前的时间，服务器端会拿到当前时间和消息中的时间相减，看看是否在一个固定的时间范围内，超过时间差的请求就视为非法请求。
限流机制 如果有用户出现频繁调用接口的情况；这种情况需要给相关用户做限流处理，常用的限流算法包括：令牌桶限流，漏桶限流，计数器限流。
令牌桶限流：系统以一定速率向桶中放入令牌，填满了就丢弃令牌；请求来时会先从桶中取出令牌，如果能取到令牌，则可以继续完成请求，否则等待或者拒绝服务。令牌桶允许一定程度突发流量，只要有令牌就可以处理，支持一次拿多个令牌； 漏桶限流：按照固定常量速率流出请求，流入请求速率任意，当请求数超过桶的容量时，新的请求等待或者拒绝服务，因此漏桶算法可以强制限制数据的传输速度； 计数器限流：这是一种比较简单粗暴的算法，主要用来限制总并发数，比如数据库连接池、线程池、秒杀的并发数；计数器限流只要一定时间内的总请求数超过设定的阀值则进行限流。 黑名单机制 如果此用户进行过很多非法操作，或者说专门有一个中黑系统，经过分析之后直接将此用户列入黑名单，所有请求直接返回错误码。
我们可以给每个用户设置一个状态比如包括：初始化状态，正常状态，中黑状态，关闭状态等等；或者我们直接通过分布式配置中心，直接保存黑名单列表，每次检查是否在列表中即可。
数据合法性校验 这应该是每个系统都会有的处理机制，只有在数据是合法的情况下才会进行数据处理；每个系统都有自己的验证规则，当然也可能有一些常规性的规则，比如身份证长度和组成，电话号码长度和组成等等。合法性校验包括：常规性校验以及业务校验。
常规性校验：包括签名校验，必填校验，长度校验，类型校验，格式校验等； 业务校验：根据实际业务而定，比如账户余额不能小于0等. 总结 本文大致列举了几种常见的API鉴权机制和安全措施，当然还有其他方式。但是我们除非为了学习，不然不建议为了用某种鉴权方式和安全措施或者用什么新技术新框架而强行使用，应该根据实际需要在这些机制的原理上做修改和组合，毕竟技术是为业务服务的。
