如何在Razor Pages中结合第三方API构建Web与API授权架构？

一、你的方案可行性分析 #

你的方案整体是可行的，核心逻辑符合Web应用+独立API的分离式架构授权设计思路，各模块的合理性如下：

• JWT认证获取令牌：这是无状态认证的标准方案，API端可通过JWT中的Claims区分用户角色（客户/员工），轻松实现公开、客户专属、员工专属三类端点的权限控制，适配多客户端（Web/桌面/移动）的需求。
• API请求令牌管理：静态HttpClient能减少连接池开销，但要注意静态HttpClient是应用级对象，不能存储单个用户的令牌——多用户并发时会出现令牌串用的问题，建议改为每个请求动态从用户会话中读取令牌并添加到请求头。
• Web应用Cookie会话：用Cookie控制Razor Pages的页面访问权限，未授权用户仅能访问登录页，这是服务器端渲染应用的常规做法，配合[Authorize]特性就能实现页面级授权，逻辑清晰。
• 令牌失效Middleware：跟踪API请求的令牌状态，失效时强制注销用户，能避免用户在无权限状态下操作，提升体验，是必要的容错机制。

二、可优化/更简便的方案建议 #

1. 修正HttpClient的令牌使用方式 #

放弃静态HttpClient存储用户令牌的做法，改用IHttpClientFactory创建客户端，在每次发起API请求时，从当前用户的HttpOnly Cookie中读取JWT，动态添加到请求头：

// 在Razor Pages页面中注入IHttpClientFactory
private readonly IHttpClientFactory _httpClientFactory;

public async Task OnGet()
{
    var client = _httpClientFactory.CreateClient("RequestApi");
    var jwtToken = Request.Cookies["JwtToken"];
    client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", jwtToken);
    // 发起API请求
    var response = await client.GetAsync("/api/customers/requests");
}

2. 添加刷新令牌机制 #

当前方案仅处理令牌失效后的注销，建议补充Refresh Token机制：

• 登录时API返回访问令牌（短有效期，比如15分钟）和刷新令牌（长有效期，比如7天）。
• 将刷新令牌存储在HttpOnly、Secure的Cookie中，避免XSS和CSRF风险。
• 当访问令牌失效时，自动调用API的刷新令牌端点，用有效刷新令牌换取新的访问令牌，无需用户重新登录。

3. 用ASP.NET Core Identity简化开发 #

如果不想手动实现用户凭据验证、角色管理等逻辑，可以引入ASP.NET Core Identity：

• API端配置JWT Bearer认证，同时用Identity管理用户、角色、密码哈希，省去自己写登录验证、用户存储的代码。
• Web应用（Razor Pages）配置Cookie认证，登录时调用API的Identity登录接口获取JWT，本地创建Cookie会话，同时将JWT存入HttpOnly Cookie供API请求使用。
• 桌面/移动应用直接使用JWT认证，登录后将令牌存储在安全位置（如移动应用的Keychain、桌面应用的加密存储）。

4. 细化API权限策略 #

除了按角色划分端点，可结合策略授权实现更精细的权限控制，比如客户只能查看自己的请求：

// API端注册策略
services.AddAuthorization(options =>
{
    options.AddPolicy("OwnRequest", policy =>
        policy.RequireAssertion(context =>
            context.User.FindFirstValue("RequestId") == context.Resource.ToString()));
});

// 在API控制器中使用
[Authorize(Policy = "OwnRequest")]
public async Task<IActionResult> GetRequest(int id)
{
    // 业务逻辑
}

三、关于Web应用与API分离的建议 #

你担心合并项目后无法单独运行API是完全合理的，保持Web应用（Razor Pages）与API的分离架构优势明显：

• API可独立部署、扩容，供Web、桌面、移动多客户端调用。
• 两个项目可独立迭代，Web应用的UI变更不会影响API的稳定性。
• 便于后续扩展，比如新增第三方客户端接入API时，无需修改Web应用代码。

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