如何在 HTTP/2 Web 应用程序中使用 Windows 身份验证（在 IIS 上）

Question

IIS 10 支持 HTTP/2，但如果网站配置为使用 Windows 身份验证，它会降级到 HTTP/1.1。

我想创建一个不需要域用户登录（Windows Auth 非常适合）但仍然能够使用 HTTP/2 的 Web 应用程序。您对如何设计有想法吗？

到目前为止我自己的想法：也许我可以将应用程序外部的 Windows Auth 放入另一个创建 JWT 的服务中，然后使用该 JWT 在主应用程序上进行身份验证。

但这增加了很多复杂性：

• Chrome 目前不会在同一域中混合 HTTP/2 和 HTTP/1.1（FF 会），因此该服务必须位于不同的域中，这意味着需要额外的 SSL 证书 + DNS 配置等。
• 我需要在对服务器的任何调用期间处理 JWT 过期问题。

因此，对于它的价值来说，这可能是太多的努力。

你能想出更好的主意吗？

Answer 1

IIS 10 支持 HTTP/2，但如果网站配置为使用 Windows 身份验证，它会降级到 HTTP/1.1。

正确的。这是因为 Windows 身份验证不支持 HTTP/2。

我想创建一个不需要域用户登录的 Web 应用程序（Windows Auth 非常适合）但仍然能够使用 HTTP/2

在 LAN 环境中运行 HTTP/2 并没有真正的优势。HTTP/2（和 HTTP/3）旨在降低用户可感知的延迟，这在 LAN 环境中不是问题。HTTP/2 还需要 TLS，但它在 LAN 中并未广泛部署（因为您不能对非公共地址使用公共 CA，因此您需要设置和维护自己的 PKI，否则您无法使用 HTTP /2 无论如何。大多数运行自己的 Active Directory 域的小型企业不会运行自己的 PKI，并且他们根本无法将 HTTP/2 用于内部应用程序 - 除非您确实想指示您的用户强制-信任自签名证书）。

到目前为止我自己的想法：也许我可以将应用程序外部的 Windows Auth 放入另一个创建 JWT 的服务中，然后使用该 JWT 在主应用程序上进行身份验证。

事实上，这是一个非常好的选择！。_{（在开始编写回复之前，我什至没有想到这种方法。）}您可以使用一个简单的侦听器来实现此方法http://localhost:12345，您的应用程序的登录页面（位于http://lan-server:80/）可以fetch在客户端脚本或中使用该侦听器进行询问<iframe>，并使用它来自动执行登入。另一种选择是设置 Chrome 扩展（现在也与 MS Edge、Firefox 和 Safari 很大程度上兼容）来向本地主机侦听器发出请求并更新用户的http://lan-servercookie。您很幸运，在 LAN 环境中工作的一个巨大优势是您不必担心客户端软件部署，因为您（或您的 IT 部门）可以确保所有设置都已完成。

Chrome 目前不会在同一域中混合 HTTP/2 和 HTTP/1.1（FF 会），因此该服务必须位于不同的域中，这意味着需要额外的 SSL 证书 + DNS 配置等。

正确的。

您遇到的基础设施和配置问题是内部和“企业”Web 应用程序消失的一个重要原因：软件供应商不希望为本地安装维护技术支持，而公司使用它们的人不想维护本地系统。以前，公司在允许另一家公司托管自己的公司数据、电子邮件、文档等方面存在巨大的信任问题（如人类信任，而不是 PKI 信任），此外还缺乏 100mbps+ 低延迟互联网连接，这使得许多类型的应用程序根本不可能 - 但这在过去十年的大部分时间里都是现实，因此现在使用 Office 365 电子邮件用户的公司可能比今天使用本地 Exchange Server 的公司多一个数量级。如果微软自己淘汰Windows Server 和传统的 Active Directory，使其成为一个庞大的 Azure/Office 365/Internet 管理的大型 MDM 系统，我不会感到惊讶- 至少这样你就可以加入 AD 域（或任何他们想要的域）。无需物理连接到本地 LAN 或 VPN-in。

我需要在对服务器的任何调用期间处理 JWT 过期问题。

这不是问题，原因有二：

1. 虽然 JWT 确实有定义的到期日期+时间，但客户端软件会在 JWT 到期之前很久就对其进行续订。应用程序不会access_token等到它已经过期之后才刷新：它们会在它过期之前执行此操作。

   _{例如：在 OAuth2/OIDC 中，refresh_token不是 JWT，而是一个短字符串（通常不会过期），客户端软件使用 来refresh_token获取新的access_token（这是JWT），而不会有access_token过期的风险。Microsoft 在 ASP.NET 中自己的 OIDC 客户端将在access_token超过规定的最大期限的一半后续订access_token- 因此，如果在发行时 JWTaccess_token距离到期还有 24 小时，则客户端将在access_token之后续订12小时。从而消除客户端使用过期 JWT 的风险。}

2. 一般来说，JWT 的过期时间仅检查一次：当请求到达服务器时，请求会立即得到处理（HTTP 是无状态的，还记得吗？），因此JWT 是否在开始发出请求后 3 秒过期并不重要。需要 10 秒才能处理的操作。_{（好吧，除非access_token将其转发到另一个资源服务器，在这种情况下，这是一个蹩脚的应用程序设计）}。

因此，对于它的价值来说，这可能是太多的努力。

我认为它的价值取决于您的应用程序。在我看来，您希望能够说您的应用程序支持 HTTP/2 来实现某些广告要点或竞争产品比较页面 - 在这种情况下，这是想要做任何事情的糟糕理由。但就本地LAN 应用程序而言，“HTTP/2 支持”的意义微乎其微，即使您提到它，也隐含着一种不诚实的比较，这种比较只吸引那些不应该做出软件采购决策的人，以及那些应该做出软件采购决策的人。知道这意味着胡言乱语将因此对你的产品产生悲观的看法。

作为开发人员或解决方案提供商，给您的建议是：不要看球在哪里，而要关注球在哪里。看看球的去向：它正在进一步进入云中。环顾四周，您会发现，与全球可访问的互联网 SaaS 应用程序托管相比，本地业务软件和 Web 应用程序现在几乎没有什么优势。通过牺牲你的产品来支持日益衰退的环境，你将失去与那些领先于你的人竞争的能力。现在 - 我假设您这样做是为了盈利......如果您是这样的话，那么我希望您正确选择目标市场，因为本地部署只会从这里开始减少。