用途：当 Axum 应用需要用服务端会话而非自包含令牌来认证用户时使用，例如带登录表单的服务端渲染 Web 应用。会话 Cookie 只携带不透明的会话 ID，用户 ID、角色、CSRF 令牌等真实状态保存在服务端会话存储中，与 JWT 的结构相反。
主要能力：Axum 本身不提供会话机制，该技能覆盖四种有状态或委托式认证方案及对应 crate：tower-sessions（原始会话层，不涉及登录逻辑）、axum-login（基于 tower-sessions，提供类型化用户、登录/登出与路由守卫）、axum-extra 的 TypedHeader（HTTP Basic，仅限 TLS 的机器间通信）、oauth2（委托给 Google、GitHub、SSO 等外部身份提供方）。JWT 属于另一技能 axum-impl-auth-jwt。
使用方式：会话层通过 .layer(SessionManagerLayer::new(store)) 添加；读取用 session.get::<T>("key").await，写入用 session.insert("key", value).await，销毁用 session.delete().await 或 flush().await，登录后轮换 ID 用 session.cycle_id().await。axum-login 需实现 AuthnBackend 与 AuthUser，用 AuthManagerLayerBuilder 组装，并用 .route_layer(login_required!(Backend, login_url = "/login")) 守卫路由。OAuth2 采用授权码加 PKCE 流程，回调后建立本地会话。
适用场景与限制：需要即时吊销登录或保存可变的服务端用户状态时选会话；需要零服务端状态与水平扩展时选 JWT。OAuth2 是身份机制而非会话机制，回调后仍需选择会话或 JWT。生产环境必须使用持久化 SessionStore（如 sqlx 或 Redis 存储），MemoryStore 仅限开发；with_secure 应在 TLS 后设为 true；登录成功后必须轮换会话 ID 以防会话固定攻击；Basic 认证必须走 TLS 并用常量时间比较哈希；OAuth2 必须先校验 state 再交换 code，且不得硬编码 client_secret。同一路由不可混用两种主认证机制。相关 crate 版本敏感，需对照 Cargo.toml 中锁定的版本确认 API 形态。