刷新Token时向IdentityServer4传递自定义参数的实现问询

这个场景我之前也碰到过，核心思路是借助IdentityServer已有的用户会话Cookie，发起静默授权请求（携带prompt=none参数），让IdentityServer在无需用户重新输入凭证的前提下，根据新的companyCode生成包含对应角色权限的新Token。下面是具体的实现步骤和代码修改：

一、Angular客户端修改：实现切换公司方法 #

不需要调用signout()，而是发起带新参数的静默授权请求，同时处理可能的静默失败场景：

async switchCompany(newCompanyCode: string) {
    // 清除客户端本地缓存的旧用户信息，避免新旧数据冲突
    await this.manager.removeUser();

    // 配置授权请求参数：prompt=none表示不显示登录页面，复用现有会话Cookie
    this.manager.settings.extraQueryParams = {
        companyCode: newCompanyCode,
        prompt: 'none'
    };

    try {
        // 发起静默授权重定向
        await this.manager.signinRedirect();
    } catch (error) {
        // 静默失败（比如Cookie过期、会话失效）时，降级到正常登录流程
        console.error('Silent company switch failed, falling back to login:', error);
        this.manager.settings.extraQueryParams = { companyCode: newCompanyCode };
        await this.manager.signinRedirect();
    }
}

二、IdentityServer后端修改：处理静默授权请求 #

在AccountController的Login方法中，增加对prompt=none请求的处理逻辑，直接复用现有会话生成新Token：

[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Login(LoginInputModel model, string button)
{
    var context = await _interaction.GetAuthorizationContextAsync(model.ReturnUrl);

    // 处理静默授权请求（prompt=none）
    if (context?.Prompt == "none")
    {
        // 检查用户是否已通过Cookie认证
        if (User.Identity.IsAuthenticated)
        {
            var user = await _userManager.GetUserAsync(User);
            if (user == null)
            {
                return BadRequest("Authenticated user not found");
            }

            // 获取新的companyCode参数
            var newCompanyCode = context.Parameters["companyCode"] ?? string.Empty;
            Claim[] additionalLocalClaims = { new Claim("companyCode", newCompanyCode) };

            // 生成新的认证会话，携带新的companyCode Claim
            var authProps = new AuthenticationProperties
            {
                RedirectUri = context.ReturnUrl
            };
            await HttpContext.SignInAsync(user.SubjectId, user.UserName, authProps, additionalLocalClaims);

            // 重定向回客户端，完成授权流程
            return Redirect(context.ReturnUrl);
        }
        else
        {
            // 用户未登录，按OIDC规范返回挑战（触发正常登录流程）
            return Challenge();
        }
    }

    // 原有正常登录逻辑（保留不变）
    // ...
}

三、确保ProfileData逻辑正确复用 #

你的CustomProfileConfiguration中的GetProfileDataAsync逻辑不需要修改，因为每次授权请求都会重新从context.Subject中读取最新的companyCode Claim，进而获取对应公司的角色权限。

关键注意事项 #

• 会话Cookie有效期：确保IdentityServer的认证Cookie有效期足够长，避免用户在切换公司时Cookie过期导致静默失败。
• 浏览器第三方Cookie限制：如果客户端和IdentityServer是跨域名部署，可能会受到浏览器第三方Cookie策略影响，此时需要调整Cookie的SameSite属性，或者考虑使用其他兼容方案。
• 客户端配置验证：确保IdentityServer中对应的客户端配置，AllowedGrantTypes包含authorization_code（PKCE流要求），且未限制prompt参数的使用。

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