本文详解如何基于 jwt + laravel passport 在 api 网关与多个微服务间构建安全、可扩展的认证授权体系，重点解决用户身份透传、角色权限携带及跨服务鉴权问题。
本文详解如何基于 jwt + laravel passport 在 api 网关与多个微服务间构建安全、可扩展的认证授权体系，重点解决用户身份透传、角色权限携带及跨服务鉴权问题。
在 Laravel 微服务架构中，将认证（Authentication）与授权（Authorization）职责合理分离是保障系统安全与可维护性的关键。推荐采用「API 网关统一认证 + 微服务本地授权」模式：所有客户端请求首先经由 API 网关完成身份校验与 JWT 解析，网关再将携带用户上下文（如 user_id、roles、scopes）的可信令牌透传至下游微服务；各微服务无需重复登录，仅需验证令牌签名有效性并基于嵌入的声明（claims）执行业务级权限控制。
✅ 正确实践：JWT 中嵌入授权信息
Laravel Passport 默认生成的 AccessToken 仅含基础用户 ID 和过期时间，不支持自定义 claims。需扩展 CreateFreshApiToken 或重写 Passport::tokensCan() 逻辑，在颁发 Token 时注入角色与权限信息：
// 在 User 模型中覆盖 createToken 方法
public function createToken(string $name, array $scopes = [])
{
// 动态添加 roles 和 permissions 到 JWT payload
$token = $this->tokens()->create([
'name' => $name,
'scopes' => $scopes,
'expires_at' => now()->addDays(7),
]);
// 手动构造带自定义 claims 的 JWT（需引入 firebase/php-jwt）
$payload = [
'sub' => $this->id,
'name' => $this->name,
'email' => $this->email,
'roles' => $this->roles->pluck('name')->toArray(), // 如 ['admin', 'editor']
'permissions' => $this->getAllPermissions()->pluck('name')->toArray(),
'iat' => now()->timestamp,
'exp' => now()->addDays(7)->timestamp,
'jti' => (string) Str::uuid(),
];
$jwt = JWT::encode($payload, config('jwt.secret'), 'HS256');
return new AccessToken($token, $jwt);
}
⚠️ 注意：生产环境应使用 RS256 非对称签名，并由网关统一管理公私钥，避免密钥泄露风险。
? API 网关层：统一鉴权与请求透传
API 网关（如 Laravel 作为反向代理网关）承担以下核心职责：
- 验证 JWT 签名与有效期（使用 firebase/php-jwt 或 tymon/jwt-auth）
- 解析 claims 并注入请求头（如 X-User-ID, X-Roles, X-Permissions）
- 转发请求至目标微服务，附带原始 JWT 或精简上下文头
示例网关中间件：
// app/Http/Middleware/ValidateJwtAndInjectContext.php
public function handle($request, Closure $next)
{
$token = $request->bearerToken();
if (!$token) {
throw new AuthenticationException('Missing token');
}
try {
$decoded = JWT::decode($token, config('jwt.secret'), ['HS256']);
$request->attributes->add([
'user_id' => $decoded->sub,
'roles' => $decoded->roles ?? [],
'permissions' => $decoded->permissions ?? [],
]);
// 注入可信头，供下游微服务直接读取（避免重复解密）
$request = $request->duplicate([], null, [
'X-User-ID' => $decoded->sub,
'X-Roles' => implode(',', $decoded->roles),
'X-Permissions' => implode(',', $decoded->permissions),
]);
return $next($request);
} catch (\Exception $e) {
throw new AuthenticationException('Invalid or expired token');
}
}
? 微服务层：无状态授权校验
各微服务（如 Posts、Orders）不再依赖数据库查询用户，而是信任网关注入的上下文头，结合本地策略（Policy）或门面（Gate）进行快速授权：
// app/Policies/PostPolicy.php
public function update(User $user, Post $post): bool
{
// 直接从请求头获取角色，而非 DB 查询
$roles = explode(',', request()->header('X-Roles', ''));
return in_array('admin', $roles) || $post->user_id === (int)request()->header('X-User-ID');
}
// 控制器中使用
public function update(UpdatePostRequest $request, Post $post)
{
$this->authorize('update', $post);
// ... 业务逻辑
}
? 服务间通信：避免敏感 Token 泄露
? 关键原则：微服务间调用不应传递原始 JWT 给第三方服务，而应使用短期、最小权限的内部令牌（如 HMAC 签名的 Service Token）或通过服务发现 + mTLS 实现双向认证。
若必须透传用户上下文（如 Core 服务调用 Users 服务获取资料），推荐方案：
- 使用 Http::withHeaders() 注入网关已验证的 X-* 上下文头
- 禁用 Cookie 传递（易被篡改），改用 Header-only 方式
- 所有内部服务端点强制校验 X-User-ID + X-Signature（HMAC-SHA256 签名）
// 微服务间安全调用示例
$response = Http::withHeaders([
'X-User-ID' => request()->header('X-User-ID'),
'X-Roles' => request()->header('X-Roles'),
'X-Signature' => hash_hmac('sha256',
request()->header('X-User-ID') . '|' . now()->toIso8601String(),
config('services.internal_secret')
),
])->get("{$this->usersMsUrl}/api/user");
✅ 总结：最佳实践清单
| 层级 | 职责 | 推荐技术 |
|---|---|---|
| API 网关 | JWT 校验、上下文注入、路由分发 | Laravel + firebase/php-jwt + 自定义中间件 |
| 用户微服务 | 用户管理、Token 颁发（含 roles/permissions claims） | Laravel Passport 扩展 + Eloquent 角色模型 |
| 业务微服务 | 基于 X-* 头做快速授权，不查库 | Gate/Policies + 请求头解析 |
| 服务通信 | 内部调用使用短期签名令牌或 mTLS | HMAC 签名 + 时间戳防重放 / gRPC over TLS |
通过该架构，你将获得：✅ 单点登录体验、✅ 权限动态更新（修改用户角色后新 Token 自动生效）、✅ 微服务无状态化、✅ 安全边界清晰。切记：永远不要在微服务间直接传递原始 JWT——它属于客户端凭证，而非服务间信任凭证。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
