分布式系统中的认证挑战
在传统单体应用中，用户登录后服务端可以通过 Session 直接管理状态，一切都在同一个进程里，简单直接。但当业务拆分成多个微服务，部署在不同服务器甚至不同区域时，问题就来了：用户登录一次，难道每个服务都要重新认证？显然不现实。
比如一个电商平台，订单、支付、用户中心各自独立部署。用户下单时，订单服务需要确认“这个人是不是已经登录”，不能因为没做认证就让人随便下单。这时候，就需要一套统一的认证机制，让各个服务都能快速、安全地识别用户身份。
常见认证方案对比
目前主流的分布式认证方案主要有两种：基于 Token 的认证和基于 OAuth2/OpenID Connect 的集中式认证。
Token 认证最典型的实现是 JWT（JSON Web Token）。用户登录成功后，服务端生成一个包含用户信息的 Token，返回给客户端。之后每次请求，客户端都带上这个 Token，各服务通过验证签名来确认其有效性，无需查数据库。
<?php
// 生成 JWT 示例（PHP）
$payload = [
'user_id' => 123,
'exp' => time() + 3600
];
$token = jwt_encode($payload, $secret_key, 'HS256');
echo $token;
?>这种方式轻量，适合服务间通信频繁的场景。但缺点也很明显：Token 一旦签发无法主动失效，除非引入黑名单机制或缩短有效期。
另一种方式是使用 OAuth2 和 OpenID Connect。比如企业内部系统，员工用统一账号登录，访问 CRM、OA、财务等多个系统。这时可以搭建一个认证中心（如 Keycloak 或 Auth0），所有服务都信任它。用户登录后拿到 Access Token，各服务向认证中心验证 Token 状态。
实际部署建议
对于中小型项目，JWT 更容易上手。只要约定好密钥、算法和字段规范，各服务接入成本低。比如用 Go 写的服务可以直接用 github.com/golang-jwt/jwt/v5 解析，Java 项目用 jjwt 库也一样。
大型系统更推荐 OAuth2 方案。虽然初期要搭认证服务器、配置客户端凭证，但后续扩展方便。比如新增一个数据分析平台，只需在认证中心注册客户端，不用改现有逻辑。
无论哪种方案，传输过程必须走 HTTPS。明文传 Token 就像把钥匙挂在门把手上，谁路过都能拿。
避免常见坑
别在 JWT 里放敏感信息。Token 是 Base64 编码，不是加密，任何人拿到都能解出来。用户名、角色可以放，密码、手机号就算了。
别用弱密钥。见过有人用 123456 当签名密钥，这种等于没签。至少用 32 位以上的随机字符串。
服务间调用也要认证。别以为“都是自己人”就走内网裸调。攻击者一旦进入内网，没有鉴权的服务就是突破口。