Как я могу контролировать сериализацию утверждений, билетов и свойств проверки подлинности на основе файлов cookie ASP.NET?

Question

• У меня есть веб-приложение ASP.NET Core 2.2 MVC, которое использует OIDC с отдельного веб-сайта.

• В Startup.cs оно имеет:

  services
      .AddAuthentication()
      .AddCookie( "Cookies", o => ... )
      .AddOpenIdConnect( "Oidc",  o => ... );
  

• access_token от поставщика идентификаторов составляет около 800 байт, а id_token - около 1500 байт.

• Когда извлекается id_token, мой код анализируетсявсе id_token запрашивают и преобразуют их в строго типизированные свойства объекта C #, а затем генерируют List<Claim> на основе этих свойств.Этот List<Claim> затем передается в метод ASP.NET Core SignInAsync.
• Однако размер файла cookie ASP.NET Core часто превышает 7000 байт (!!), и он настолько большой, что распространяетсяболее 2 или 3 файлов cookie (с помощью функции Chunked Cookies в ASP.NET Core).Это вызывает проблему, поскольку Chrome иногда отклоняет файлы cookie, размер которых превышает 4096 байт.
• Я использовал этот прием (https://stackoverflow.com/a/55729188/159145) для преобразования фрагментированных файлов cookie в один двоичный файл, который я использовал для проверки шестнадцатеричного редактора.и я увидел, как использовалось пространство:
  • Каждый из Claim элементов из моего List<Claim> сериализуется (как и ожидалось), но каждый Claim ClaimValueType также сериализуется сполный URI эмитента (23 байта) и полный URI типа данных XML, например, "http://www.w3.org/2001/XMLSchema#integer" (40 байт) (я отмечаю, что ASP.NET Core, по-видимому, пропускает полный URI типа данных XML, если он "http://www.w3.org/2001/XMLSchema#string" - это прискорбно, потому чтопричина, по которой я использовал integer, в первую очередь заключалась в том, чтобы сэкономить место от строкового кодирования и кавычек.
    • В совокупности все они используют около 1900 байт из 7000-байтового cookie.
  • Далее сохраняются различные значения OIDC, такие как AuthScheme.oidc\r.sessionState и .Token.access_token”. Я отмечаю, что эти значения уже закодированы в Base64 и затем дважды кодируются ASP.NET Core. (Так что, если ASP.NET Core был умнееn-кодировать любые значения Base64 и представлять их как их исходную двоичную форму, затем передать это в защиту данных (шифрование) и затем запустить external-Base64 - но я отступаю.
  • После этого .Token.id_token избыточно хранится.Это избыточно, потому что все заявки id_token были проанализированы в ClaimsIdentity - но в AddOpenIdConnect нет опции, чтобы только сохранить access_token в куки пользователя и удалить id_token.
    • На самом деле, id_token должен быть сохранен, потому что необходимо использовать функцию выхода из OIDC hint (оригинальная строка id_token должна быть предоставлена ​​обратно IP, дословно).

Я вижу несколько возможностей для оптимизации этого - но в Интернете очень мало документации о том, как это сделать.

• Могу ли япредотвратить сериализацию любых (или большинства) значений Claim, и вместо этого ASP.NET Core материализует объекты Claim путем повторного анализа id_token?
• Я могу использовать ASP.NET Coreконечную точку информации пользователя для утверждений вместо использования id_token, но как мне это сделать, при этом гарантируя, что я получу все необходимые ресурсы OpenID Identity?
• Как я могу обеспечить сериализацию каждого значения Claimэффективно?
• Как я могу предотвратить двойное Base64-кодирование таких вещей, как значения access_token и id_token?