public Tuple<IPrincipal, IDictionary<string, string>> SignInEntry { get { return _context.Get<Tuple<IPrincipal, IDictionary<string, string>>>(OwinConstants.Security.SignIn); } set { _context.Set(OwinConstants.Security.SignIn, value); } }
其中，_context的类型为IOwinContext，OwinConstants.Security.SignIn的常量值为"security.SignIn"。
跟踪完毕……
啥？跟踪这么久，居然跟丢啦！？
当然没有！但接下来就需要一定的技巧了。
原来，ASP.NET是一种中间件（Middleware）模型，在这个例子中，它会先处理MVC中间件，该中间件处理流程到设置AuthenticationResponseGrant/SignInEntry为止。但接下来会继续执行CookieAuthentication中间件，该中间件的核心代码在aspnet/AspNetKatana仓库中可以看到，关键类是CookieAuthenticationHandler，核心代码如下：
protected override async Task ApplyResponseGrantAsync() { AuthenticationResponseGrant signin = Helper.LookupSignIn(Options.AuthenticationType); // ... 省略部分代码 if (shouldSignin) { var signInContext = new CookieResponseSignInContext( Context, Options, Options.AuthenticationType, signin.Identity, signin.Properties, cookieOptions); // ... 省略部分代码 model = new AuthenticationTicket(signInContext.Identity, signInContext.Properties); // ... 省略部分代码 string cookieValue = Options.TicketDataFormat.Protect(model); Options.CookieManager.AppendResponseCookie( Context, Options.CookieName, cookieValue, signInContext.CookieOptions); } // ... 又省略部分代码 }
这个原始函数有超过200行代码，这里我省略了较多，但保留了关键、核心部分，想查阅原始代码可以移步Github链接：
这里挑几点最重要的讲。
与MVC建立关系
建立关系的核心代码就是第一行，它从上文中提到的位置取回了AuthenticationResponseGrant，该Grant保存了Claims、AuthenticationTicket等Cookie重要组成部分：
AuthenticationResponseGrant signin = Helper.LookupSignIn(Options.AuthenticationType);
继续查阅LookupSignIn源代码，可看到，它就是从上文中的AuthenticationManager中取回了AuthenticationResponseGrant（有删减）：
public AuthenticationResponseGrant LookupSignIn(string authenticationType) { // ... AuthenticationResponseGrant grant = _context.Authentication.AuthenticationResponseGrant; // ... foreach (var claimsIdentity in grant.Principal.Identities) { if (string.Equals(authenticationType, claimsIdentity.AuthenticationType, StringComparison.Ordinal)) { return new AuthenticationResponseGrant(claimsIdentity, grant.Properties ?? new AuthenticationProperties()); } } return null; }
如此一来，柳暗花明又一村，所有的线索就立即又明朗了。
Cookie的生成
从AuthenticationTicket变成Cookie字节串，最关键的一步在这里：
string cookieValue = Options.TicketDataFormat.Protect(model);
在接下来的代码中，只提到使用CookieManager将该Cookie字节串添加到Http响应中，翻阅CookieManager可以看到如下代码：
public void AppendResponseCookie(IOwinContext context, string key, string value, CookieOptions options) { if (context == null) { throw new ArgumentNullException("context"); } if (options == null) { throw new ArgumentNullException("options"); } IHeaderDictionary responseHeaders = context.Response.Headers; // 省去“1万”行计算chunk和处理细节的流程 responseHeaders.AppendValues(Constants.Headers.SetCookie, chunks); }
有兴趣的朋友可以访问Github看原始版本的代码：
可见这个实现比较……简单，就是往Response.Headers中加了个头，重点只要看TicketDataFormat.Protect方法即可。
逐渐明朗
该方法源代码如下：
public string Protect(TData data) { byte[] userData = _serializer.Serialize(data); byte[] protectedData = _protector.Protect(userData); string protectedText = _encoder.Encode(protectedData); return protectedText; }
可见它依赖于_serializer、_protector、_encoder三个类，其中，_serializer的关键代码如下：
public virtual byte[] Serialize(AuthenticationTicket model) { using (var memory = new MemoryStream()) { using (var compression = new GZipStream(memory, CompressionLevel.Optimal)) { using (var writer = new BinaryWriter(compression)) { Write(writer, model); } } return memory.ToArray(); } }
其本质是进行了一次二进制序列化，并紧接着进行了gzip压缩，确保Cookie大小不要失去控制（因为.NET的二进制序列化结果较大，并且微软喜欢搞xml，更大😂）。
然后来看一下_encoder源代码：
public string Encode(byte[] data) { if (data == null) { throw new ArgumentNullException("data"); } return Convert.ToBase64String(data).TrimEnd('=').Replace('+', '-').Replace('https://www.jb51.net/', '_'); }
可见就是进行了一次简单的base64-url编码，注意该编码把=号删掉了，所以在base64-url解码时，需要补=号。
这两个都比较简单，稍复杂的是_protector，它的类型是IDataProtector。
IDataProtector
它在CookieAuthenticationMiddleware中进行了初始化，创建代码和参数如下：
IDataProtector dataProtector = app.CreateDataProtector( typeof(CookieAuthenticationMiddleware).FullName, Options.AuthenticationType, "v1");