SignInManager.PasswordSignInAsync用户数据存储位置及Cookie机制说明

你贴的是ASP.NET Identity 2.x（MVC5默认项目模板自带的身份认证实现）的标准登录逻辑，默认采用客户端Cookie存储加密认证数据的方案，不是服务端存会话、客户端仅存SessionID的模式，哪怕项目用SQL Server存用户基础数据，默认也不会在服务端额外留存认证会话记录。

Cookie中存储的具体内容 #

SignInManager.PasswordSignInAsync登录成功后，认证中间件会生成经过数据保护API加密、加签的认证票据写入Cookie，解密后的核心内容包括：

• 用户核心标识：用户主键Id（也就是UserManager对应的用户表主键，默认是字符串格式的Guid）
• 认证元数据：票据签发时间、过期时间、是否持久化（对应代码里的model.RememberMe参数，勾选记住我时Cookie有效期会大幅延长）、所属认证方案名称
• 登录时加载的用户声明（Claims）：用户名、所属角色、登录流程中注入的所有自定义声明

你推测的「后续请求无需重复查库即可构建User主体」是正确的：后续请求到达时，认证中间件只要解密Cookie、校验签名和有效期合法，就能直接构建出完整的ClaimsPrincipal用户对象，不需要访问数据库。要注意的是，这部分存在Cookie里的角色、声明是登录那一刻从数据库加载的快照，如果后续用户角色、权限发生变更，要等用户重新登录或者主动刷新认证票据才会生效。

和服务端Session模式的区别 #

默认实现下不存在「服务端存储会话、Cookie只存关联ID」的逻辑：

• 这套Cookie认证是无状态的，服务端不会在SQL Server、内存或其他存储位置保存和当前认证Cookie对应的会话记录，验证过程完全依赖Cookie本身的加密签名合法性
• 所有Cookie内容都经过机器级密钥加密加签，用户无法自行篡改、伪造内容，只要内容被修改，签名校验就会失败，请求会直接被判定为未认证。

特殊配置场景说明 #

只有你手动修改认证配置、自定义实现ITicketStore接口接入服务端存储（比如存Redis、SQL Server、分布式缓存）时，才会切换为第二种存储模式：此时Cookie中只会存储一个加密的票据关联Key，中间件验证请求时会拿这个Key去配置好的服务端存储拉取完整认证票据。你贴的代码是默认模板生成的标准代码，没有做这类自定义改造，因此走的是默认的客户端加密存储方案。

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