IIS 10支持HTTP/2，但如果网站配置为使用Windows身份验证，则会降级为HTTP/1.1。
我想创建一个不需要域用户登录的web应用程序(Windows Auth非常适合)，但仍然可以使用HTTP/2。你对如何设计有想法吗？
到目前为止，我自己的想法是：也许我可以将应用程序外的Windows身份验证应用到另一个创建JWT的服务中，然后使用该JWT在主应用程序上进行身份验证。
然而，这增加了很多复杂性：
- Chrome目前没有在同一个域中混合HTTP/2和HTTP/1.1(FF是这样做的)，因此服务必须在不同的域上，这意味着需要额外的SSL证书+DNS配置等
- 在任何对服务器的调用过程中，我都需要处理JWT过期问题
所以这可能付出了太多的努力。
你能想出更好的主意吗？
IIS 10支持HTTP/2，但如果网站配置为使用Windows身份验证，则会降级为HTTP/1.1。
正确。这是因为Windows身份验证不支持HTTP/2。
我想创建一个不需要域用户登录的web应用程序(Windows Auth非常适合)，但仍然可以使用HTTP/2
在局域网环境中运行HTTP/2并没有真正的优势。HTTP/2(和HTTP/3)旨在降低用户可感知的延迟，这在局域网环境中不是问题。HTTP/2还需要TLS，它没有广泛部署在局域网中(因为你不能将公共CA用于非公共地址，所以你需要设置和维护你自己的PKI，否则你无论如何都不能使用HTTP/2。大多数运行自己的Active Directory域的小企业将不会运行自己的PKI。他们将根本无法将HTTP/2用于内部应用程序，除非你真的想指示你的用户强制信任自己-签名证书)。
到目前为止，我自己的想法是：也许我可以将应用程序外的Windows身份验证应用到另一个创建JWT的服务中，然后使用该JWT在主应用程序上进行身份验证。
实际上，这是一个非常好的选择(在我开始写响应之前，我甚至没有想过这种方法。)您可以使用一个简单的http://localhost:12345侦听器来实现这一点，您的应用程序的登录页面(位于http://lan-server:80/)可以使用客户端脚本中的fetch或<iframe>来询问该侦听器，并使用它来自动登录。另一种选择是设置一个Chrome扩展(现在也与MS Edge、Firefox和Safari基本兼容)，向本地主机侦听器发出请求并更新用户的http://lan-servercookie。幸运的是，在局域网环境中工作的一个巨大优势是，您不必担心客户端软件部署，因为您(或您的IT部门)可以确保一切都已就绪。
Chrome目前没有在同一个域中混合HTTP/2和HTTP/1.1(FF是这样做的)，因此服务必须在不同的域上，这意味着需要额外的SSL证书+DNS配置等。
正确。
您遇到的基础设施和配置问题是内部和"；企业-y；web应用程序正在消失：软件供应商不想维护对on-prem安装的技术支持，使用它们的公司也不想维护on-prem系统。以前，公司在允许另一家公司托管自己的公司数据、电子邮件、，文档等，再加上缺乏100mbps以上的低延迟互联网连接，这使得许多类型的应用程序根本不可能实现，但这在过去十年的大部分时间里都是现实，因此，现在使用Office 365电子邮件用户的公司可能比使用prem Exchange Server的公司多出一个数量级。如果微软自己淘汰了Windows Server和传统的Active Directory，使其成为一个庞大的Azure/Office 365/互联网管理的巨型MDM系统，我也不会感到惊讶——至少这样，你就可以加入AD域(或他们当时称之为什么)，而无需物理连接到预局域网或使用VPN。
在对服务器的任何调用过程中，我都需要处理JWT过期问题。
这不是问题，原因有两个：
-
虽然JWT确实有一个定义的到期日期+时间，但客户端软件会在到期之前很长一段时间续订任何JWT。应用程序不会等待刷新
access_token，直到它已经过期：它们会在过期之前进行刷新。例如：在OAuth2/OIDC中，
refresh_token不是JWT，而是一个短字符串(通常不会过期)，客户端软件使用refresh_token来获得新的access_token(是JWT)，而不会有access_token过期的风险。微软在ASP。NET将在超过access_token规定的最大使用期限的一半时续订access_token，因此，如果在发布时，JWTaccess_token的有效期还有24小时，则客户端将在12小时后续订access_token。从而消除了客户使用过期JWT的风险 -
JWT的过期通常只检查一次：当请求到达服务器时，请求会立即得到处理(HTTP是无状态的，还记得吗(好吧，除非
access_token被转发到另一个资源服务器，在这种情况下，这是一个糟糕的应用程序设计)。
所以这可能付出了太多的努力。
我认为它的价值取决于您的应用程序。在我看来，你似乎希望能够说你的应用程序支持HTTP/2用于某些广告要点或竞争产品比较页面——在这种情况下，这是想要做任何事情的糟糕理由。但就在prem上的LAN应用而言；HTTP/2支持"；意思是太少，以至于即使你提到它，也隐含着在进行一种不诚实的比较，这种比较只会吸引那些不应该做出软件采购决定的人——而那些知道这意味着胡说八道的人会因此对你的产品持悲观态度。
作为开发人员或解决方案提供商的建议：不要看球在哪里；看看球的方向：它正在进一步进入云。环顾四周，发现与全球可访问的互联网SaaS应用程序托管相比，在线商业软件和网络应用程序现在几乎没有什么优势。通过牺牲你的产品来支持日益衰退的环境，你将失去与那些超前思考的人竞争的能力。现在-我想你是为了盈利。。。如果你是，我希望你正确地选择了你的目标市场，因为从这里开始，市场份额只会减少。