微服务架构中是否需将认证设为独立服务？功能及调用解析

我的问题 #

我正尝试确定是否应将认证功能抽象为应用中的独立服务。若将其设为独立微服务是合理方案，该服务具体应实现哪些功能？我初步想法是让它颁发JWT令牌并按需验证，但这样会不会导致每个应用都要重复编写认证代码？我对OpenID Connect概念还比较陌生，即便阅读了文档仍不太理解。

以下是我设想的该微服务应具备的代码：

public string CreateToken(User user)
{
    List<Claim> claims = new List<Claim>
    {
        new Claim(ClaimTypes.Name, user.Name),
        //new Claim(ClaimTypes.Role, "Anonymous")

    };

    var key = new SymmetricSecurityKey(System.Text.Encoding.UTF8.GetBytes(
        _config.GetSection("AppSettings:Token").Value));

    var cred = new SigningCredentials(key, SecurityAlgorithms.HmacSha512Signature);

    var token = new JwtSecurityToken(
        claims: claims,
        expires: DateTime.Now.AddMinutes(30),
        signingCredentials: cred);

    var jwt = new JwtSecurityTokenHandler().WriteToken(token);
    
    return jwt;
}

public bool ValidateToken(string token)
{
    var tokenHandler = new JwtSecurityTokenHandler();
    var validationParameters = 
    new TokenValidationParameters
    {
        ValidateIssuerSigningKey = true,
        IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8
.GetBytes(_config["Jwt:Key"])),
        ValidIssuer = _config["Jwt:Issuer"],
        ValidAudience = _config["Jwt:Issuer"],
        ValidateIssuer = true,
        ValidateAudience = true,
        ValidateLifetime = true
    };

    SecurityToken validatedToken;
    IPrincipal principal = tokenHandler.ValidateToken(token, validationParameters, out validatedToken);
    return true;
}

最后，若最终将认证功能抽象为独立微服务，其他微服务应如何调用它？感谢您的时间，抱歉问题较多，我只是想确保理解正确。

解答 #

一、是否该将认证抽象为独立微服务？ #

如果你的系统是多服务架构（比如多个微服务、多前端应用），或者未来有扩展多应用的计划，把认证做成独立服务完全合理。核心优势：

• 统一认证逻辑，避免重复实现
• 集中管理用户身份、权限策略
• 便于统一更新认证规则（比如加密算法、令牌有效期）
• 降低单个服务的复杂度

如果只是单应用，暂时没必要，反而会增加架构复杂度。

二、认证微服务应实现的核心功能 #

你的JWT生成/验证是基础，但还需要补充这些核心能力：

• 用户身份校验：账号密码登录校验、第三方登录（微信/Google等）的对接逻辑
• 令牌生命周期管理：
  • 颁发访问令牌（Access Token）：完善现有CreateToken，补充角色、权限、用户ID等必要Claim
  • 刷新令牌（Refresh Token）：用于Access Token过期时，无需重新登录即可获取新令牌
  • 令牌吊销：支持主动失效指定令牌（比如用户注销、密码修改场景）
• 权限基础能力：
  • 角色、权限的存储与查询（若权限逻辑复杂可拆分到独立权限服务，但基础角色Claim需嵌入令牌）
  • 提供权限校验接口（供其他服务调用，或直接把权限信息写入令牌）
• OpenID Connect相关（可选但推荐）：
  OIDC是基于OAuth2的标准化身份认证协议，核心是帮你把「用户登录-获取身份-验证身份」的流程规范化。若实现OIDC，你的服务需要支持：
  • 授权端点：处理用户登录授权流程
  • 令牌端点：颁发Access Token、ID Token（包含用户核心身份信息的令牌）、Refresh Token
  • 用户信息端点：供客户端获取用户详细身份数据
    简单来说，OIDC能帮你避免自己搭建非标准的认证流程，减少重复造轮子的成本。

三、会不会导致每个应用重复写认证代码？ #

不会，反而能大幅减少重复工作：

• 前端应用：只需跳转到认证服务完成登录，获取令牌后，每次请求携带令牌即可，无需自己实现登录逻辑
• 后端微服务：无需重复编写令牌验证代码，可封装一个公共认证中间件（比如ASP.NET Core的JWT中间件），所有微服务引入该中间件并配置好验证参数（签名密钥、Issuer等），就能自动验证请求头中的JWT，无需调用认证服务（因为JWT是自包含令牌，本地即可完成签名、有效期等校验）
  • 仅特殊场景（比如令牌主动吊销校验）才需要调用认证服务

四、其他微服务如何调用认证服务？ #

分两种场景处理：

1. 令牌本地验证（推荐）：
   利用JWT自包含特性，其他微服务直接通过本地中间件验证令牌的签名、有效期、Issuer/Audience等信息，无需调用认证服务。这种方式性能更高，减少服务间依赖。
   注意：所有服务需共享相同的签名密钥（或认证服务提供公钥，采用非对称加密签名）。

2. 调用认证服务接口（仅特殊场景）：
   若需要验证令牌是否被主动吊销，或获取用户最新权限信息，其他服务可通过内网HTTP请求调用认证服务的校验接口，传入令牌后获取验证结果和用户信息。
   调用时注意：

   • 使用内部API调用，无需暴露到公网
   • 可添加服务间认证（比如服务账号令牌），确保只有可信服务能调用

五、现有代码的优化建议 #

• 统一管理签名密钥、Issuer、Audience等配置，避免硬编码或分散配置
• 补充Refresh Token的生成与验证逻辑，提升用户体验
• 令牌中加入更多必要Claim：用户ID、角色、权限、租户ID（多租户场景）
• 考虑采用非对称加密（比如RSA）签名JWT，认证服务用私钥签名，其他服务用公钥验证，无需共享密钥，安全性更高

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