在设计网站或平台时，我们经常需要向用户开放 API 访问。这允许用户以编程方式调用某些功能。例如：

• 允许用户通过 API 访问和管理其账户数据
• 允许开发人员使用我们的 API 集成外部应用程序
• 允许第三方服务访问我们的数据以提供额外的服务

当我们向用户开放 API 访问时，我们需要确保每次 API 调用都经过鉴权。这意味着我们需要确认用户是他们所声称的身份。

有两种常见的方法用于实现 API 鉴权：

• 基于令牌的鉴权
• 基于 HMAC 的鉴权

基于令牌的鉴权

1. 用户在客户端输入密码，然后客户端将密码发送到鉴权服务器。
2. 鉴权服务器验证密码并生成一个有有效期的令牌。
3. 客户端可以发送请求，使用 HTTP 头中带有的令牌访问服务器资源。这种访问在令牌过期前一直有效。

基于令牌的鉴权通常适用于需要保持长时间会话的情况，例如当用户登录网站或应用程序时。令牌可以存储在客户端或服务器端，客户端可以在每次调用 API 时将其发送到服务器。

基于 HMAC 的鉴权

1. 服务器生成两个密钥，一个是公共 ID（公钥），另一个是 APIKey（私钥）。
2. 客户端生成一个 HMAC 签名（hmacA），该签名是根据请求的数据（例如请求路径、请求正文和时间戳）和 APIKey 计算得出的。
3. 客户端发送请求，HTTP 头中包含 hmacA。
4. 服务器收到请求并验证 hmacA。服务器使用存储在服务器端的 APIKey 计算自己的 HMAC 签名（hmacB）。
5. 如果 hmacA 和 hmacB 匹配，则请求被授权，资源被返回给客户端。

基于 HMAC 的鉴权通常适用于需要防止重放攻击的情况。由于 HMAC 签名包括时间戳，因此无法重用签名。这使得基于 HMAC 的鉴权非常适合于涉及敏感数据的 API 调用。

选择合适的鉴权机制

• 会话的持续时间：基于令牌的鉴权更适合于需要保持长时间会话的情况，而基于 HMAC 的鉴权更适合于需要防止重放攻击的短期会话。
• 安全性：基于 HMAC 的鉴权通常被认为比基于令牌的鉴权更安全，因为 HMAC 签名包括时间戳，并且无法重用。
• 易用性：基于令牌的鉴权通常比基于 HMAC 的鉴权更容易实现，因为不需要在客户端生成签名。

通过考虑这些因素，您可以选择最适合您的应用程序的 API 鉴权机制。

API 安全

API 安全主要包括 信息安全 、 网络安全 、 应用安全 三个方面

信息安全 是你要保证系统所有的信息在它的整个的 生命周期 中，它应该是受到保护的，是安全的 所谓整个 生命周期 包括信息从创建开始、到存储、到转换、到备份、甚至到销毁

应用的设计上抵挡各种攻击，防范各种风险

确保信息只被预期的用户访问

防止未授权的创建、修改、删除

当用户需要访问 API 时，服务总是可用的

伪装 成某人【例如，我不是系统管理员，但是我伪装成系统管理员，然后我想干什么干什么】

将不希望被修改的数据、消息或设置改掉【比如说修改法币订单的状态，用户把钱付了后，允许用户把订单的状态从未付款变为已付款，但是不允许用户在修改自己订单的时候，把其他人的订单也修改了】

拒绝承认做过的事情【比如说用户需要退款，然后我们给它退款了，但是他拒绝承认已经退掉的款】

将你希望保密的信息批漏出来【如用户信息的泄漏】

拒绝用户访问信息和服务【最常见的是DDOS 攻击，把你的服务压垮，把你的服务都堵住，让你没法为用户提供服务】

做了你不希望他能做的事

解决了拒绝服务的 API 安全风险 流控可以防止用户请求淹没你的 API

解决了 欺骗 的 API 安全风险 认证可以确保你的用户或者客户端真的是他【它】们自己

解决了否认 的 API 安全风险 审计可以确保所有操作都被记录，以便追溯和监控

解决了 信息泄漏 、 干预 、 越权 的 API 安全风险 授权可以确保每个针对 API 的访问都是经过授权的

解决了 信息泄漏 的 API 安全风险 加密可以确保出入 API 的数据是私密的

所谓 认证 就是验证用户身份是否合法的过程；认证 的作用是验证用户传进来的用户身份【比如校验用户传过来的请求头 Authorition】 而 登录 是 用户获取身份证明的一个过程【用于用户获取身份】

授权用于做访问控制的

要遵循最小的授权原则【一个用户只给他必须要的权限，不要的权限都不给他，什么时候有需要时再申请】

1. 你的请求是不是需要身份认证或者需要权限控制

2. 判断你有没有权限

1. ACL【Acess Control Lists】

如何保证API接口安全？

在实际的业务开发过程中，我们常常会碰到需要与第三方互联网公司进行技术对接，例如支付宝支付对接、微信支付对接、高德地图查询对接等等服务，如果你是一个创业型互联网，大部分可能都是对接别的公司api接口。 当你的公司体量上来了时候，这个时候可能有一些公司开始找你进行技术对接了，转变成由你来提供api接口，那这个时候，我们应该如何设计并保证API接口安全呢？ 最常用的方案，主要有两种： 其中 token 方案，是一种在web端使用最广的接口鉴权方案，我记得在之前写过一篇《手把手教你，使用JWT实现单点登录》的文章，里面介绍的比较详细，有兴趣的朋友可以看一下，没了解的也没关系，我们在此简单的介绍一下 token 方案。 从上图，我们可以很清晰的看到，token 方案的实现主要有以下几个步骤： 在实际使用过程中，当用户登录成功之后，生成的token存放在redis中时是有时效的，一般设置为2个小时，过了2个小时之后会自动失效，这个时候我们就需要重新登录，然后再次获取有效token。 token方案，是目前业务类型的项目当中使用最广的方案，而且实用性非常高，可以很有效的防止黑客们进行抓包、爬取数据。 但是 token 方案也有一些缺点！最明显的就是与第三方公司进行接口对接的时候，当你的接口请求量非常大，这个时候 token 突然失效了，会有大量的接口请求失败。 这个我深有体会，我记得在很早的时候，跟一家中、大型互联网公司进行联调的时候，他们提供给我的接口对接方案就是token方案，当时我司的流量高峰期时候，请求他们的接口大量报错，原因就是因为token失效了，当token失效时，我们会调用他们刷新token接口，刷新完成之后，在token失效与重新刷新token这个时间间隔期间，就会出现大量的请求失败的日志，因此在实际API对接过程中，我不推荐大家采用 token方案。 接口签名，顾名思义，就是通过一些签名规则对参数进行签名，然后把签名的信息放入请求头部，服务端收到客户端请求之后，同样的只需要按照已定的规则生产对应的签名串与客户端的签名信息进行对比，如果一致，就进入业务处理流程；如果不通过，就提示签名验证失败。 在接口签名方案中，主要有四个核心参数： 其中签名的生成规则，分两个步骤： 参数2加密结果，就是我们要的最终签名串。 接口签名方案，尤其是在接口请求量很大的情况下，依然很稳定。 换句话说，你可以将接口签名看作成对token方案的一种补充。 但是如果想把接口签名方案，推广到前后端对接，答案是：不适合。 因为签名计算非常复杂，其次，就是容易泄漏appsecret！ 说了这么多，下面我们就一起来用程序实践一下吧！ 就像上文所说，token方案重点在于，当用户登录成功之后，我们只需要生成好对应的token，然后将其返回给前端，在下次请求业务接口的时候，需要把token带上。 具体的实践，也可以分两种： 下面，我们介绍的是第二种实现方式。 首先，编写一个jwt 工具。 接着，我们在登录的时候，生成一个token，然后返回给客户端。 最后，编写一个统一拦截器，用于验证客户端传入的token是否有效。 在生成token的时候，我们可以将一些基本的用户信息，例如用户ID、用户姓名，存入token中，这样当token鉴权通过之后，我们只需要通过解析里面的信息，即可获取对应的用户ID，可以省下去数据库查询一些基本信息的操作。 同时，使用的过程中，尽量不要存放敏感信息，因为很容易被黑客解析！ 同样的思路，站在服务端验证的角度，我们可以先编写一个签名拦截器，验证客户端传入的参数是否合法，只要有一项不合法，就提示错误。 具体代码实践如下： 签名工具类SignUtil ： 签名计算，可以换成hamc 方式进行计算，思路大致一样。 上面介绍的token和接口签名方案，对外都可以对提供的接口起到保护作用，防止别人篡改请求，或者模拟请求。 但是缺少对数据自身的安全保护，即请求的参数和返回的数据都是有可能被别人拦截获取的，而这些数据又是明文的，所以只要被拦截，就能获得相应的业务数据。 对于这种情况，推荐大家对请求参数和返回参数进行加密处理，例如RSA、AES等加密工具。 同时，在生产环境，采用https 方式进行传输，可以起到很好的安全保护作用！