SAML回复URL返回302重定向时如何设置Cookie？

一、正确的Cookie设置方式 #

你之前的代码思路完全错误——HttpRequestMessage是用来构造向其他服务器发送的请求，而我们需要的是在给客户端返回的302响应中添加Set-Cookie头，让浏览器把Cookie带到后续的目标页面请求里。

在你的.NET ApiController Action中，直接操作当前请求的HttpContext.Response来设置Cookie，示例代码如下：

public IActionResult SamlCallback()
{
    // 先完成SAML用户验证逻辑...

    // 设置Cookie，注意配置安全属性
    var cookieOptions = new CookieOptions
    {
        HttpOnly = true, // 禁止JS读取，防范XSS攻击
        Secure = true, // 仅在HTTPS下传输，必须开启
        SameSite = SameSiteMode.Strict, // 防范CSRF攻击
        Domain = "ourApp.com", // 必须和Login.aspx所在域名一致
        Path = "/", // 确保整个站点都能访问到该Cookie
        Expires = DateTimeOffset.UtcNow.AddMinutes(5) // 短有效期，降低风险
    };
    HttpContext.Response.Cookies.Append("sso_user_info", "加密后的用户信息", cookieOptions);

    // 重定向到目标页面
    return Redirect("https://ourApp/Login.aspx");
}

之后在Login.aspx的后台代码中，即可通过Request.Cookies["sso_user_info"]获取到Cookie值。

二、原有代码不生效的原因 #

你创建HttpRequestMessage并添加Cookie头的操作，只是在构造一个本地请求对象，这个对象和返回给客户端的302响应完全无关——浏览器根本看不到这个请求里的Cookie头，自然不会在后续请求中带上。

三、替代方案（若Cookie无法生效） #

如果因为跨域（Api和aspx页面不在同一域名）、浏览器Cookie策略限制等原因无法使用Cookie，可以考虑以下方案：

1. 临时令牌+后端存储 #

• 生成一个短有效期的唯一令牌（比如GUID），将加密后的用户信息存储到Redis/内存缓存/数据库中，与该令牌关联。
• 把令牌作为GET参数传递给Login.aspx（例如https://ourApp/Login.aspx?t=xxx）。
• Login.aspx后台拿到令牌后，从存储中取出对应的用户信息，立即删除该令牌（避免重复使用）。
• 优点：实现简单，跨域也能使用；缺点：需要依赖后端存储。

2. 自动提交POST表单 #

• 不直接返回302重定向，而是返回一个包含自动提交表单的HTML页面，表单的action指向Login.aspx，用户信息放在表单的隐藏字段中。
• 示例代码：

public IActionResult SamlCallback()
{
    // 完成SAML验证后，构造自动提交的HTML
    var userInfo = "加密后的用户信息";
    var html = $@"
    <html>
        <body onload=""document.forms[0].submit()"">
            <form method=""POST"" action=""https://ourApp/Login.aspx"">
                <input type=""hidden"" name=""sso_user"" value=""{userInfo}"">
            </form>
        </body>
    </html>";
    return Content(html, "text/html");
}

• Login.aspx后台通过Request.Form["sso_user"]获取用户信息，完成登录流程。
• 优点：用户信息不会出现在URL中，跨域也支持；缺点：会有短暂的HTML页面跳转过程。

3. 加密GET参数 #

如果必须使用GET参数，对用户信息进行强加密（比如AES加密，密钥仅存储在后端），即使参数被复制，没有密钥也无法解密出有效信息。不过这种方案只是降低风险，安全性不如前两种。

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