原文出处
Trailmax Tech
Max Vasilyev: ASP.Net MVC development in Aberdeen, Scotland
我的读者联系到我，并向我提出了一系列关于 AspNet Identity的问题。一开始我觉得这些问题都会比较简单，我能够轻松的回答他，但结果表明，这里面的每一个问题都值得写一篇单独的文章。所以我会写一个Mini系列关于Identity框架的“Q-A（问与答）”博客。
第一个问题是关于Cookie安全Token以及它是如何被计算（computed）出来的：如果同一个用户在 Chrome 和Firefox中登陆，那么Identity Framework 在Cookie中创建token,token包含相同的信息（用户Id、 Security Stamp、等等），但是为甚么这两个Cookie是不同的？
我思考了一下，我猜 cookie创建信息和过期信息被编码在了cookie中，可能还有cookie的某种签名信息也被一同保存了。我觉得我猜的很接近答案。
幸运的是，处理cookie的代码就在开源的 Katana Project 中。
下面就是用户登录是cookie的创建过程
- Identity framework根据你数据库中的信息创建
ClaimsPrincipal对象（它对应于ApplicationUser类） - Identity向principal中添加一些列默认claim，例如ApplicationUser.Id和SecurityStamp
ClaimsPrincipal被传递到CookieAuthenticationHandler这个OWIN中间件中- Authentication Handler对不同的东西都做了很多检查，比如，检查每个cookie是否应该被标记为secure或者persistent，设置过期时间等等很多事情。这一系列检查（checks，含有操作的意思）的结果就是生成一个
AuthenticationTicket,这个AuthenticationTicket拥有一个含有一系列claim和AuthenticationProperties（认证属性）的ClaimsIdentity,AuthenticationProperties是一个包含很多数据的字典（dictionary），里面的数据可能是 cookie issue 日期,过期日期,是否持久保存cookie，等等 - 认证票据和claims principal接下来被传递到
SecureDataFormat类中,数据将在这个类中序列化、加密、Base64编码
最后一步包含很多动作，我们再深入些。
认证票据由TicketSerializer进行序列化。这里ClaimsIdentity被写入内存流：包含一些属性和一个claim列表。然后AuthenticationProperties（包括cookie 设置，过期日期）也被写入了内存流。然后内存流被GZip压缩，以备接下来的处理。
管道中的下一步就是加密。加密操作由 .Net 类库中的DpapiDataProtector提供。你可以在MSDN上阅读相关文档。我不确定加密的强度。文档中说目标参数事实上是一个密码列表。现在我在OWIN中看到了一个地方你可以在这里设置你自己的加密密码，而且我看到这里主密码是“Microsoft.Owin.Security.IDataProtector”。所以我的猜测是安全的信息不应该被放进cookie里，比如：别把连接字符串放在claim里！（注：这里的翻译可能不准确，建议此段参考阅读原文）
Next step in the pipeline is encryption. Encryption is borrowed from .Net class DpapiDataProtector. You can read documentation on MSDN. I’m not sure about the strength of the encryption. The documentation says that purpose parameters are effectively a list of passwords. And now here I’ve seen in OWIN where you can set your own encryption password and I can see that the main password is set to “Microsoft.Owin.Security.IDataProtector”. So my guess would be that no secure information should go into cookie, i.e. don’t put your connection strings into user claims!
在加密之后，字节流使用Base64编码以易于网络传输。最后准备好以等待被设置到Http响应的cookie头上。
所有的过程如下图所示
反正，原来的问题：“为什么在不同浏览器中的cookies是不同的？”的答案是：因为签名中包含cookie的创建信息和过期时间，这在不同浏览器中是不同的，所以cookie中的加密信息也是不同的，所以cookie也是不同的。
