.NET WebApi无Identity实现OAuth+JWT认证的相关问题

一、自定义OAuth流程的正确性与内置实现方式 #

你梳理的自定义流程完全符合OAuth 2.0授权码模式的标准步骤，没有问题。

至于内置实现，ASP.NET Core的AddOAuth确实可以适配你的需求，只是默认绑定Cookie认证，并非只能用Cookie。你可以通过调整配置，让它生成JWT而不生成无用Cookie——毕竟它封装了很多手动实现容易忽略的细节，比如CSRF状态验证、授权码交换的错误处理、后端请求的超时重试等，比手动写端点更规范。

二、AddOAuth配置的问题与优化 #

你的代码里生成无用Cookie，是因为指定了SignInScheme = "Google-Cookie"，这个配置会让框架把OAuth认证后的身份信息存入Cookie。要禁用它，你可以：

1. 移除AddCookie("Google-Cookie")的配置，不指定SignInScheme
2. 在OnCreatingTicket事件中直接返回JWT，并终止后续的Cookie认证流程

优化后的代码示例：

services.AddOAuth("Google", options =>
{
    options.ClientId = configuration["ClientId"];
    options.ClientSecret = configuration["ClientSecret"];

    options.AuthorizationEndpoint = "https://github.com/login/oauth/authorize";
    options.TokenEndpoint = "https://github.com/login/oauth/access_token";
    options.UserInformationEndpoint = "https://api.github.com/user";

    options.CallbackPath = "/api/Google-Redirect";

    options.Scope.Clear();
    options.Scope.Add("read:user");
    options.SaveTokens = false; // 不需要保存第三方Token到认证属性，直接使用即可

    options.Events.OnCreatingTicket = async context =>
    {
        // 获取第三方用户信息
        using var request = new HttpRequestMessage(HttpMethod.Get, options.UserInformationEndpoint);
        request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", context.AccessToken);
        using var result = await context.Backchannel.SendAsync(request);
        var user = await result.Content.ReadFromJsonAsync<JsonElement>();

        // 生成与现有账号密码流程一致的JWT
        var claims = new Claim[]
        {
            new Claim(ClaimTypes.Name, user.GetProperty("name").GetString()!),
            new Claim(ClaimTypes.Email, user.GetProperty("email").GetString()!)
        };

        var token = new JwtSecurityToken(
            issuer: configuration["JWT_Issuer"],
            audience: configuration["JWT_Audience"],
            claims: claims,
            expires: DateTime.UtcNow.AddHours(1),
            signingCredentials: new SigningCredentials(
                new SymmetricSecurityKey(Encoding.UTF8.GetBytes(configuration["JWT_Secret"])),
                SecurityAlgorithms.HmacSha256
            )
        );
        var tokenString = new JwtSecurityTokenHandler().WriteToken(token);

        // 生成Refresh Token（复用现有流程的逻辑）
        var refreshToken = Guid.NewGuid().ToString();
        // 将refreshToken存入数据库并关联用户信息

        // 直接返回响应，终止框架默认的认证流程
        context.Response.ContentType = "application/json";
        await context.Response.WriteAsJsonAsync(new
        {
            AccessToken = tokenString
            // 可在此处将Refresh Token写入HttpOnly Cookie
        });
        context.HandleResponse(); // 关键：阻止后续默认的SignIn逻辑执行
    };
});

三、JWT相关疑问解答 #

1. Refresh Token的类型与加密 #

• Refresh Token推荐用随机字符串（比如GUID），而非JWT。JWT是自包含令牌，一旦泄露无法主动撤销（除非维护黑名单）；随机字符串存储在数据库中，可随时标记失效，安全性更高。
• 存储Refresh Token前必须加密，哪怕存在数据库里，也要防止数据泄露时直接拿到可用的Token。可以用ASP.NET Core的IDataProtector或对称加密算法处理。

2. HttpOnly Cookie的存储策略 #

你的计划是合理的：

• Refresh Token存入HttpOnly Cookie：HttpOnly Cookie不会被前端JS访问，能有效防止XSS攻击窃取Token。
• AccessToken返回在响应体中：前端拿到后存在内存（如Vuex/Redux），不要存入localStorage/sessionStorage（易被XSS窃取），AccessToken有效期短，即使泄露危害也较小。

四、整合现有账号密码流程的建议 #

不用放弃AddOAuth，优化后的配置可以和你现有流程完全对齐：不管是账号密码登录还是OAuth登录，最终都生成相同格式的AccessToken和Refresh Token，后端验证JWT的逻辑无需改动。

如果坚持用自定义端点流程，必须注意：

• 生成并验证state参数（防止CSRF攻击）
• 处理授权码交换时的各类错误（如无效授权码、过期授权码）
• 对第三方后端请求添加超时、重试机制

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