如何基于Auth0实现Next.js应用与AWS API Gateway的会话认证

下面给出两种完全符合你需求的落地路径，均不需要编写复杂自定义认证逻辑，也无需经过Next.js服务端代理：

方案1：原生JWT Authorizer集成（行业通用标准方案，推荐） #

该方案完全复用Auth0和AWS API Gateway的原生能力，零自定义代码，无额外安全风险：

• 第一步：在Auth0控制台为你的api.example.com接口服务创建独立的API受众（Audience），填写自定义标识（如https://api.example.com）
• 第二步：调整前端Auth0登录的授权请求参数，新增audience字段值为上一步创建的API标识，此时Auth0返回的Access Token即为该API专用的合法JWT
• 第三步：前端发起接口请求时，统一在请求头中携带Authorization: Bearer <Access Token>，可通过请求拦截器全局配置，无需业务代码额外处理
• 第四步：在AWS API Gateway控制台为对应API配置JWT Authorizer，Issuer字段填写你的Auth0租户域名，Audience字段填写之前创建的API标识，API Gateway会自动完成JWT的签名校验、有效期校验、权限校验，校验通过才转发请求到后端，失败直接返回401/403状态码
• 额外配置：在API Gateway的CORS规则中允许example.com源，允许Authorization请求头，开启Access-Control-Allow-Credentials即可

方案2：子域名Cookie共享实现（匹配你最初的设计思路） #

该方案可以实现Cookie自动携带，前端无需处理Token存储：

• 第一步：在Auth0应用设置中将会话Cookie的Domain属性修改为.example.com，确保浏览器请求api.example.com时会自动携带对应的会话Cookie
• 第二步：两种校验方式二选一即可：
  • 方式A：配置API Gateway的参数映射规则，原生提取Cookie中的Auth0会话Token到Authorization请求头，后续复用方案1的JWT Authorizer校验逻辑，全程无自定义代码
  • 方式B：使用Auth0官方提供的API Gateway Lambda Authorizer模板，仅需填写你的Auth0租户配置即可直接部署，无需编写认证逻辑，即可完成Cookie会话的合法性校验

注意事项 #

两种方案均完全绕开Next.js服务端代理，没有额外的往返耗时，和你之前使用Next.js pages/api的认证体验完全一致，且所有认证逻辑均由Auth0和AWS的原生能力提供，无需你自行维护安全相关代码。

内容的提问来源于stack exchange，提问作者PhantomSheepHorse