ASP.NET Core中，UseSession()能否在UseAuthentication()和UseAuthorization()之前使用？

我维护着一个使用Session、Authentication和Authorization的ASP.NET代码库，当前中间件初始化顺序如下：

app.UseSession();
app.UseAuthentication();
app.UseAuthorization();

根据官方《中间件顺序》文档，app.UseSession()应置于认证、授权中间件之后，但文档同时补充说明：

会话中间件（UseSession）用于建立和维护会话状态。如果应用使用会话状态，请在Cookie Policy中间件之后、MVC中间件之前调用会话中间件。

我们的应用通过自定义认证代码处理不同流程，其中一个流程需要在Session中初始化部分数据——如果将app.UseSession()移到认证/授权中间件之后，触发该流程时应用会崩溃。请问将app.UseSession()保留在另外两者之前是否安全？

结论：可以保留当前顺序，但需注意几个关键风险点 #

把UseSession()放在认证、授权之前并非完全不可行，只要规避以下问题，就能安全运行：

• 认证票据的会话依赖风险：如果你的认证方案（比如Cookie认证）依赖会话存储票据，提前启用Session可能导致认证流程无法正确关联会话数据。但如果你的自定义认证逻辑独立于会话（仅用Session存储业务初始化数据），这个风险就不存在。
• 会话劫持的潜在攻击面：会话Cookie在用户未认证时就会被建立，意味着未登录用户也能创建会话。建议给未认证用户的会话设置更短的超时时间，或者在用户完成认证后重新生成会话ID（通过HttpContext.Session.Clear()后写入新数据触发），减少劫持风险。
• 服务器资源浪费问题：官方推荐把UseSession()放在认证之后，核心原因是多数场景下会话服务于已认证用户，提前启用会存储大量未认证用户的会话数据，浪费服务器资源。如果你的业务场景确实需要在认证前用Session，这个资源成本是可接受的。

折中优化建议 #

如果只有特定的自定义认证流程需要提前使用Session，可以不用全局调整顺序，而是针对该流程的路由单独处理：

// 针对需要提前会话的路径启用Session
app.MapWhen(context => context.Request.Path.StartsWithSegments("/custom-auth-flow"), app =>
{
    app.UseSession();
    app.UseAuthentication();
    app.UseAuthorization();
    // 后续中间件
});

// 其他路径遵循官方推荐顺序
app.UseAuthentication();
app.UseAuthorization();
app.UseSession();
// 后续中间件

同时确保自定义认证代码中的Session初始化逻辑是幂等的，避免重复写入导致的异常。

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