IIS 10 supports HTTP/2 but it downgrades to HTTP/1.1 if the web site is configured to use Windows Authentication.
Correct. This is because Windows Authentication does not support HTTP/2.
I would like to create a web application that doesn't require domain users to log in (Windows Auth is perfect for that) but still being able to use HTTP/2
There are no real advantages to running HTTP/2 in a LAN environment. HTTP/2 (and HTTP/3) are designed to keep user-perceivable latency down, which isn't a problem in LAN environments. HTTP/2 also requires TLS, which is not widely deployed in a LAN (as you can't use a public CA for non-public addresses, so you need to setup and maintain your own PKI, without that you can't use HTTP/2 anyway. Most small-businesses running their own Active Directory domain won't be running their own PKI and they won't be able to use HTTP/2 at all for internal applications - unless you really want to instruct your users to force-trust a self-signed certificate).
My own thoughts so far: Maybe I could take the Windows Auth outside the app into a different service that creates a JWT and then use that JWT to authenticate on the main app.
Actually, this is a perfectly fine option!. (I didn't even think of this approach before I started writing my response.) You can implement this with a simple http://localhost:12345 listener that your application's logon page (at http://lan-server:80/) can interrogate using fetch in a client-script or an <iframe> and use that to auto-sign-in. Another alternative is to set-up a Chrome extension (which are largely compatible with MS Edge, Firefox and Safari now too) to make the requests to the localhost listener and update the user's http://lan-server cookies. You're lucky that a huge advantage of working in a LAN environment is that you don't have to worry about client-side software deployment because you (or your IT dept) can ensure that it's all set-up already.
Chrome currently doesn't mix HTTP/2 and HTTP/1.1 in the same domain (FF does), so that service has to be on a different domain, implying an additional SSL certificate + DNS config, etc.
Correct.
The infrastructure and configuration issues you're experiencing are a significant reason why internal and "enterprise-y" web-applications are disappearing: software-vendors don't want to have to maintain tech-support for on-prem installations, and the companies that use them don't want to have to maintain an on-prem system. Previously companies had massive trust issues (as in human trust, not PKI trust) in allowing another company to host their own corporate data, emails, documents and the like - in addition to the lack of availability of 100mbps+ low-latency internet connections which made many kinds of applications simply impossible - but that's been a reality for most of the past decade now and hence why there's probably now an order-of-magnitude more companies using Office 365 E-mail users than those on-prem Exchange Server today. It wouldn't surprise me if Microsoft themselves kill-off Windows Server and traditional Active Directory make it all one massive Azure/Office 365/Internet-managed mega-MDM system - at least that way you could join an AD domain (or whatever they call it at that point) without needing to be physically connected to your on-prem LAN or having to VPN-in.
I would need to handle JWT expiration during any call to the server.
This isn't a problem for two reasons:
While it's true that a JWT has a defined expiration date+time, client software will renews any JWTs long before it's due to expire. Applications don't wait to refresh an access_token until after it's already expired: they do it before it expires.
For example: in OAuth2/OIDC the refresh_token is not a JWT, but is a short string (which generally doesn't expire), and the client software uses the refresh_token to get a new access_token (which is a JWT) without risking that the access_token expires. Microsoft's own OIDC client in ASP.NET will renew an access_token about half-way past the access_token's stated maximum-age - so if at-time-of-issue, a JWT access_token's expiry is 24 hours away, the client will renew the access_token after 12 hours. Thus eliminating the risk of the client using an expired JWT.
A JWT's expiration is generally-speaking only checked once: when the request hits the server - requests are handled instantly (HTTP is stateless, remember?) so it doesn't matter if a JWT expires 3 seconds after it starts making a request for an operation that takes 10 seconds to process. (well, unless the access_token is being forwarded to another resource-server, in which case that's a crappy application design).
So that might be too much effort for what it's worth.
I argue what it's worth depends on your application. It sounds to me like you want to be able to say that your application supports HTTP/2 for some advertising bullet-point or competitive product comparison page - in which case that's a bad reason for wanting to do anything. But as far as on-prem LAN applications are concerned "HTTP/2 support" means so little that even you mentioning it is implicitly making an dishonest comparison that appeals only to people who should not be making software procurement decisions - and the people that do know it means bollocks will consequently take a dim view of your product.
As an advice for you as a developer or solution provider: don't look at where the ball is; look at where the ball is heading: and it's heading further into the cloud. Look around and see that on-prem business software and web-applications now offer little advantages over globally-accessible Internet SaaS application hosting. By compromising your product to support a declining environment you'll lose your ability to compete with those thinking ahead of you. Now - I assume you're in this for profit... and if you are then I hope that you are choosing your target-markets correctly because on-prem is only going to dwindle-down from here.
