当前位置：首页 > article >正文

API网关 - JWT认证；原理概述与具体实践样例

article 2024/11/4 15:23:58

API网关主要提供的能力，就是协议转换，安全，限流等能力。

本文主要是分享如何基于API网关实现 JWT 认证。

包含了JWT认证的流程，原理，与具体的配置样例

API网关认证的重要性

在现代Web应用和微服务架构中，API网关作为系统对外提供服务的入口点，其安全性和可靠性显得尤为重要。为了保护您对外提供的API，防止恶意访问、未授权访问、应用漏洞以及黑客攻击等潜在威胁，从而避免由此导致的数据丢失或资产损失，实施有效的认证机制是至关重要的。

2. 流程描述

通过引入JWT（Json Web Token）这样的结构化令牌来实现基于token的身份验证，具体流程如下：

客户端首先向API网关发起认证请求，通常这一步会包含用户的基本凭证，如用户名与密码。

API网关将该请求转发至后端的服务进行处理。

后端服务完成对提交凭证的有效性检查后，如果验证成功，则利用预设的私钥生成一个带有时间限制及其他必要声明的新JWT。

这个新生成的JWT被封装进响应并由API网关返回给客户端。

客户端保存收到的JWT，并在未来向API发出的每一个请求中都携带这个token。

当API网关接收到含有有效JWT的请求时，它使用之前配置好的公钥来解码和验证这个token的真实性及有效性。只有当这些步骤全部通过了才会允许请求继续传递到实际的目标服务。

目标服务执行相应的逻辑操作，并最终通过API网关把结果回传给原始调用方。

采用上述方法不仅能够确保只有经过身份验证的用户才能访问敏感数据和服务，同时也简化了跨多个服务间共享身份信息的过程。此外，由于每个JWT都是独立的且包含了所有必要的认证细节，因此即使在网络传输过程中被捕获也难以被篡改或重复使用，进一步增强了系统的安全性。

API网关常用认证方式解析

API密钥认证：适合轻量级安全需求场景，如内部系统间通信。优势在于简单易用、实现快速；劣势是安全性较低，一旦泄露可能导致服务滥用。

OAuth 2.0：适用于需要授权第三方应用访问资源的场景。优点为灵活性高，支持多种授权模式；缺点是复杂度较高，实施成本大。

JWT（JSON Web Tokens）：适合分布式微服务架构下的身份验证。其优势是无状态、可跨域使用；但令牌体积较大且一旦签发后无法撤销为其不足之处。

Basic Auth：用于对安全性要求不高的场合。易于实现是其主要优点；然而，它以明文形式传输用户名密码，存在较大安全隐患。

HMAC签名：常用于确保消息完整性和来源真实性。能够有效防止中间人攻击，但在大规模部署时可能因计算签名消耗较多资源而显得效率低下。

通过常见认证方式解析网关认证的核心机制

以最常用的认证方式为例，介绍网关认证的基本原理

在讨论基于JWT的认证机制时，首先需要理解这种令牌（token）是如何帮助实现安全且高效的身份验证过程。根据提供的参考资料，下面将详细介绍使用JWT进行API网关认证的基本流程。整个过程涉及客户端、API网关以及后端服务之间的交互。

客户端发起认证请求：当用户尝试访问受保护资源时，第一步是通过用户名和密码或其他形式的身份凭据向API网关发送一个认证请求。

网关转发请求至后端服务：收到认证请求后，API网关不会自行处理这个请求而是将其直接转发给负责验证用户身份的后端服务或系统。

后端服务验证用户信息并生成Token：后端服务接收到转发过来的认证请求后，会校验其中包含的用户凭证。如果这些凭证有效，则该服务利用事先配置好的私钥来生成一个JWT。这个过程中可能还包括设置一些关于此令牌的有效期限等属性。

返回带有Token的响应：一旦成功创建了JWT，后端服务将其作为响应的一部分发回给API网关。随后，API网关再将此包含JWT的响应返回给最初的请求者——客户端。此时，客户端应当保存好这个令牌以便后续使用。

客户端携带Token发起业务请求：每当客户端想要访问任何需要权限控制的服务时，都必须在其HTTP请求中附加之前获得的JWT。这通常可以通过在请求头中加入Authorization: Bearer <token>的方式完成。

网关验证Token有效性：对于每个到达的请求，API网关都会检查是否存在有效的JWT，并且尝试使用存储于其配置中的公钥对该JWT进行解码及验证。这里主要检查的是签名是否正确、令牌是否过期等因素。

验证通过后转发请求：只有当JWT被确认为合法且未超时的情况下，API网关才会继续处理该请求并将之传递给相应的后端服务。反之，若发现令牌无效或已失效，则应拒绝此次访问并立即终止流程。

后端执行逻辑并回复结果：最后一步是由实际提供服务的应用程序来处理经过认证后的请求，完成后它会将处理结果经由API网关反向传回到原始客户端那里。

以上步骤概述了一个完整的基于JWT的API网关认证流程。需要注意的是，在实际部署时还需要考虑到诸如密钥管理、异常处理等额外的安全措施以确保整个系统的稳定性和安全性。

Higress概述

Higress是一个基于Envoy和Istio构建的云原生API网关，它集成了流量网关、微服务网关以及安全网关的功能，深度支持Dubbo、Nacos等微服务技术栈，能够显著降低用户的部署与运维成本。特别值得一提的是，Higress仅通过简单的配置就可以支持大部分的安全认证方式，包括但不限于基本认证、JWT、OAuth2.0等，这极大地提高了系统安全性的同时也保证了操作的便捷性和灵活性。

JWT认证配置的详尽指南

JWT认证的详细配置方式

基于Higress实现JWT认证需要进行一系列详细的配置步骤。以下将详细介绍如何通过Higress的配置来实现JWT认证，包括全局配置、消费者配置以及路由级配置的具体流程和代码示例。

1. 全局配置

首先，你需要在全局配置中定义jwt-auth插件的基本设置。这些设置包括是否启用全局认证机制（global_auth），以及定义服务调用者（consumers）的相关信息。

配置示例：

# 全局配置
consumers:
- name: consumer1
  issuer: abcd
  jwks: |
    {
      "keys": [
        {
          "kty": "oct",
          "kid": "123",
          "k": "hM0k3AbXBPpKOGg__Ql2Obcq7s60myWDpbHXzgKUQdYo7YCRp0gUqkCnbGSvZ2rGEl4YFkKqIqW7mTHdj-bcqXpNr-NOznEyMpVPOIlqG_NWVC3dydBgcsIZIdD-MR2AQceEaxriPA_VmiUCwfwL2Bhs6_i7eolXoY11EapLQtutz0BV6ZxQQ4dYUmct--7PLNb4BWJyQeWu0QfbIthnvhYllyl2dgeLTEJT58wzFz5HeNMNz8ohY5K0XaKAe5cepryqoXLhA-V-O1OjSG8lCNdKS09OY6O0fkyweKEtuDfien5tHHSsHXoAxYEHPFcSRL4bFPLZ0orTt1_4zpyfew",
          "alg": "HS256"
        }
      ]
    }

- name: consumer2
  issuer: abc
  jwks: |
    {
      "keys": [
        {
          "kty": "RSA",
          "e": "AQAB",
          "use": "sig",
          "kid": "123",
          "alg": "RS256",
          "n": "i0B67f1jggT9QJlZ_8QL9QQ56LfurrqDhpuu8BxtVcfxrYmaXaCtqTn7OfCuca7cGHdrJIjq99rz890NmYFZuvhaZ-LMt2iyiSb9LZJAeJmHf7ecguXS_-4x3hvbsrgUDi9tlg7xxbqGYcrco3anmalAFxsbswtu2PAXLtTnUo6aYwZsWA6ksq4FL3-anPNL5oZUgIp3HGyhhLTLdlQcC83jzxbguOim-0OEz-N4fniTYRivK7MlibHKrJfO3xa_6whBS07HW4Ydc37ZN3Rx9Ov3ZyV0idFblU519nUdqp_inXj1eEpynlxH60Ys_aTU2POGZh_25KXGdF_ZC_MSRw"
        }
      ]
    }

global_auth: false

consumers: 定义了多个服务调用者，每个调用者都需要指定name、issuer和jwks。

jwks: 是一个JSON Web Key Set，用于验证JWT签名。

global_auth: 如果设置为true，则全局生效认证机制；如果设置为false，则只对做了配置的域名和路由生效认证机制。

2. 路由级配置

接下来，你需要为特定的路由或域名配置允许访问的消费者列表。

配置示例：

# 对 route-a 和 route-b 这两个路由做如下配置：
allow:
- consumer1

# 对 *.example.com 和 test.com 在这两个域名做如下配置：
allow:
- consumer2

allow: 指定该匹配条件下允许访问的调用者列表。

当请求匹配到这些路由或域名时，只有在allow列表中的消费者才能访问。

3. 配置字段详解

为了更好地理解上述配置，以下是各个配置字段的详细说明：

consumers:

- name: 消费者的名称。

- issuer: JWT的签发者，需要和payload中的iss字段保持一致。

- jwks: JSON Web Key Set，用于验证JWT签名。

- claims_to_headers: 抽取JWT的payload中指定字段，设置到指定的请求头中转发给后端。

- from_headers: 从指定的请求头中抽取JWT。

- from_params: 从指定的URL参数中抽取JWT。

- from_cookies: 从指定的cookie中抽取JWT。

- clock_skew_seconds: 校验JWT的exp和iat字段时允许的时钟偏移量，单位为秒。

- keep_token: 转发给后端时是否保留JWT。

global_auth: 是否启用全局认证机制。

allow: 对特定路由或域名允许访问的消费者列表。

4. 常见错误码说明

在配置过程中，可能会遇到一些常见的错误码，这些错误码及其原因如下：

HTTP 状态码	出错信息	原因说明
401	Jwt missing	请求头未提供JWT
401	Jwt expired	JWT已经过期
401	Jwt verification fails	JWT payload校验失败，如iss不匹配
403	Access Denied	无权限访问当前路由