原文出处
Max Vasilyev: ASP.Net MVC development in Aberdeen, Scotland
I’ve been reached out by one of my readers with a list of questions about AspNet Identity. First I thought the questions will be easy and I’ll wing them, but turned out that every single question in the list is worth of a separate blog post. So I’ll do a mini-series of Q-A posts about Identity framework and related stuff.
我的读者联系到我，并向我提出了一系列关于 AspNet Identity的问题。一开始我觉得这些问题都会比较简单，我能够轻松的回答他，但结果表明，这里面的每一个问题都值得写一篇单独的文章。所以我会写一个Mini系列关于Identity框架的“Q-A（问与答）”博客。
First question is about security token in a Cookie and how it is computed: Identity Framework creates a token in the cookie, token containing the same information (User.Id, Security Stamp, etc.); if the same user loggen-in in Chrome and Firefox, why are the cookies different?
第一个问题是关于Cookie安全Token以及它是如何被计算（computed）出来的：如果同一个用户在 Chrome 和Firefox中登陆，那么Identity Framework 在Cookie中创建token,token包含相同的信息（用户Id、 Security Stamp、等等），但是为甚么这两个Cookie是不同的？
I did think about it for a while, I guessed that cookie creation and expiration is encoded in the cookie, along with some sort of signature of the cookie. My guess was not far from the real world.
我思考了一下，我猜 cookie创建信息和过期信息被编码在了cookie中，可能还有cookie的某种签名信息也被一同保存了。我觉得我猜的很接近答案。
Fortunately, the code that deals with cookies is in Katana Project and is open-sourced.
幸运的是，处理cookie的代码就在开源的 Katana Project 中。
Here is the pipeline how cookie is created on user sign-in:
下面就是用户登录是cookie的创建过程
- Identity framework creates ClaimsPrincipal object from the record in your database (that is represented by ApplicationUser class)
Identity framework根据你数据库中的信息创建ClaimsPrincipal对象（它对应于ApplicationUser类） - Identity adds list of default claims like ApplicationUser.Id and SecurityStamp to the claims on the principal.
Identity向principal中添加一些列默认claim，例如ApplicationUser.Id和SecurityStamp - ClaimsPrincipal is passed to OWIN middleware: CookieAuthenticationHandler
ClaimsPrincipal被传递到CookieAuthenticationHandler这个OWIN中间件中 - Authentication Handler is doing a lot of checking for different things, like should the cookie be marked as secure or persistent, sets the expiry date and many other things. Result of these checks is AuthenticationTicket which has ClaimsIdentity with list of claims and AuthenticationProperties which is a dictionary with load of data like cookie issue date, expiry date, is cookie persistent, etc.
Authentication Handler对不同的东西都做了很多检查，比如，检查每个cookie是否应该被标记为secure或者persistent，设置过期时间等等很多事情。这一系列检查（checks，含有操作的意思）的结果就是生成一个AuthenticationTicket,这个AuthenticationTicket拥有一个含有一系列claim和AuthenticationProperties（认证属性）的ClaimsIdentity,AuthenticationProperties是一个包含很多数据的字典（dictionary），里面的数据可能是 cookie issue 日期,过期日期,是否持久保存cookie，等等 - Auth ticket and claims principal is then passed down to SecureDataFormat class where data is serialised, encrypted and Base64 encoded.
认证票据和claims principal接下来被传递到
SecureDataFormat类中,数据将在这个类中序列化、加密、Base64编码
The last step contains a lot of movements, let’s look deeper into it.
最后一步包含很多动作，我们再深入些。
Authentication ticket is serialised via TicketSerializer. There ClaimsIdentity is written into memory stream: some properties and list of the claims. Then AuthenticationProperties (with cookie set, expiry dates) is also written to memory stream. Then this memory stream is GZipped and returned for further processing.
认证票据由TicketSerializer进行序列化。这里ClaimsIdentity被写入内存流：包含一些属性和一个claim列表。然后AuthenticationProperties（包括cookie 设置，过期日期）也被写入了内存流。然后内存流被GZip压缩，以备接下来的处理。
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!
管道中的下一步就是加密。加密操作由 .Net 类库中的DpapiDataProtector提供。你可以在MSDN上阅读相关文档。我不确定加密的强度。文档中说目标参数事实上是一个密码列表。现在我在OWIN中看到了一个地方你可以在这里设置你自己的加密密码，而且我看到这里主密码是“Microsoft.Owin.Security.IDataProtector”。所以我的猜测是安全的信息不应该被放进cookie里，比如：别把连接字符串放在claim里！（注：这里的翻译可能不准确，建议此段参考阅读原文）
After the encryption, stream of bytes is Base64-encoded to be transferable over the wire. And finally prepared to be set as a cookie header on HTTP Response.
在加密之后，字节流使用Base64编码以易于网络传输。最后准备好以等待被设置到Http响应的cookie头上。
Overall the process will look like this great drawing:
所有的过程如下图所示
Anyway, the answer to the original question why the cookies are different in different browsers would be as follows: because part of the signature contains cookie creation and expiry dates, these would be different in different browsers. So data encrypted in cookie turns out to be different, the value of the cookie will be different.
反正，原来的问题：“为什么在不同浏览器中的cookies是不同的？”的答案是：因为签名中包含cookie的创建信息和过期时间，这在不同浏览器中是不同的，所以cookie中的加密信息也是不同的，所以cookie也是不同的。
