Laravel登录时生成Access/Refresh Token的优化实现方案咨询

你的临时方案（内部调用自身/oauth/token端点）并不合理，核心问题是额外的HTTP请求会增加不必要的性能开销，完全没必要多绕这一层。下面是两种更优的实现方式：

方式一：直接调用Passport底层逻辑生成令牌（推荐） #

这种方式跳过HTTP请求，直接利用Passport的授权服务生成令牌，同时能灵活加入自定义业务逻辑（比如记录登录日志、更新用户最后登录时间）。

步骤与代码示例： #

1. 确保已生成密码授权客户端（执行php artisan passport:client --password命令，记录生成的client_id和client_secret，也可直接从oauth_clients表查询password_client = true的记录）。
2. 在自定义登录控制器中实现逻辑：

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Hash;
use App\Models\User;
use Laravel\Passport\Client;
use League\OAuth2\Server\AuthorizationServer;

public function login(Request $request)
{
    // 验证输入参数
    $validated = $request->validate([
        'email' => 'required|email',
        'password' => 'required',
    ]);

    // 查询用户
    $user = User::where('email', $validated['email'])->first();

    // 验证密码有效性
    if (!$user || !Hash::check($validated['password'], $user->password)) {
        return response()->json(['message' => '邮箱或密码错误'], 401);
    }

    // 获取密码授权客户端（建议将client_id和client_secret存入.env配置）
    $client = Client::where('password_client', true)->first();
    if (!$client) {
        return response()->json(['message' => '未配置密码授权客户端'], 500);
    }

    // 借助Passport的授权服务生成令牌
    $server = app(AuthorizationServer::class);
    $tokenResponse = $server->respondToAccessTokenRequest(
        $request->create('/', 'POST', [
            'grant_type' => 'password',
            'client_id' => $client->id,
            'client_secret' => $client->secret,
            'username' => $validated['email'],
            'password' => $validated['password'],
            'scope' => '',
        ]),
        new \League\OAuth2\Server\ResponseTypes\BearerTokenResponse()
    );

    // 自定义业务逻辑：比如更新用户最后登录时间
    $user->update(['last_login_at' => now()]);

    // 返回令牌数据
    return response()->json($tokenResponse->getParameters());
}

方式二：让前端直接调用Passport原生端点 #

如果你的登录流程不需要额外业务逻辑，可以直接让前端请求Passport提供的/oauth/token端点，传递grant_type=password及其他必填参数，无需自定义任何API端点。

注意事项： #

• 前端需要知晓密码授权客户端的client_id和client_secret，SPA应用建议使用personal access client或配置password_client为公开，生产环境需注意密钥安全，避免泄露。

为什么不推荐内部HTTP调用？ #

• 性能损耗：额外的内部HTTP请求会增加响应时间和服务器负载；
• 配置风险：多环境部署时需确保内部调用域名配置一致，容易出现环境适配问题；
• 排查困难：令牌生成出错时，需要排查两层请求链路，增加调试成本。

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