如何控制ASP.NET核心Cookie身份验证的声明、票证和属性的序列化？

Question

• 我有一个ASP.NET Core2.2MVCWeb应用程序，它从一个单独的网站使用OIDC。
• 在Startup.cs中，它有： services .AddAuthentication() .AddCookie( "Cookies"，o => .) .AddOpenIdConnect( "Oidc"，o => . )；
• ID提供程序的access_token约为800个字节，id_token约为1500个字节。
• 当检索到id_token时，我的代码会解析所有的id_token声明，并将它们转换为强类型的C#对象属性，然后根据这些属性生成List<Claim>。然后将这个List<Claim>传递到ASP.NET Core的SignInAsync方法中。
• 然而，发出的ASP.NET核心cookie通常超过7,000个字节(!!)它是如此之大，以至于它分散在2到3个cookies上(使用ASP.NET Core的块饼干功能)。这会导致问题，因为Chrome有时会拒绝超过4096字节的cookie。
• 我使用这个技巧( https://stackoverflow.com/a/55729188/159145 )将分块的cookie转换成一个二进制文件，我使用十六进制编辑器来检查这个二进制文件，我看到了这个空间是如何被使用的：。
  • 我的Claim中的每个List<Claim>项都是序列化的(如预期的)，但是每个Claim的ClaimValueType也被序列化为完整的发出者URI (23个字节)和完整的XML数据类型URI，例如"http://www.w3.org/2001/XMLSchema#integer" (40个字节)(我注意到ASP.NET Core似乎省略了完整的XML数据类型URI，如果它是"http://www.w3.org/2001/XMLSchema#string"的话)--这是不幸的，因为我最初使用integer的原因是为了从字符串编码和引号中节省空间。
  • 综合起来，这些都使用了7,000个字节cookie中的大约1,900字节。

​

- Next, the various OIDC values are stored, such as the `AuthScheme.oidc\r.sessionState` and `.Token.access_token”`. I note that these values are Base64-encoded already and are then doubly encoded by ASP.NET Core. (So if ASP.NET Core was smarter it would un-encode any Base64 values and represent them as their original binary form, then pass that into the data-protection (encryption) and then run the outer-Base64 - but I digress.
- After that, the `.Token.id_token` is redundantly stored. This is redundant because all of the `id_token`'s claims have been parsed out into the `ClaimsIdentity` - but there's no option in `AddOpenIdConnect` to only save `access_token` into the user's cookie and to drop the `id_token`.  
    - Actually, the `id_token` must be saved because it's needed to use the OIDC sign-out `hint` feature (the original `id_token` string must be provided back to the IP, verbatim).

​

​

我看到了一些优化这一点的可能性--但是网上很少有关于如何实现它的文档。

• 我是否可以阻止任何(或大部分) Claim值被序列化，而是让ASP.NET核心通过重新解析id_token来实现Claim对象
• 我可以让ASP.NET核心使用User Identity进行索赔，而不是使用id_token，但是如何做到这一点，同时仍然确保我获得了所需的所有OpenID标识资源？
• 如何确保有效地序列化每个Claim值？
• 如何防止像access_token和id_token值这样的东西进行双Base64 64编码？

Answer 1

两年后，有人推翻了我的问题--发帖促使我从2019年6月起将我的公关代码发布到ASP.NET核心团队(这是 encrypting user-provided input opens you up to the CRIME and BREACH vulnerabilities )--或许需要一段时间才能让你对它有好感，但这是有道理的，我同意@Blowdart拒绝将其作为通用代码的决定。

...however我知道，如果cookie中没有不可信/未经验证的用户提供的秘密，那么如果您所存储的只是一些非机密或固定大小的值(例如Int32)，而远程用户无法控制，那么它就不会真正容易受到犯罪/破坏的影响：

享受：https://github.com/Jehoel/aspnetcore-auth-cookie-optimizations