JWT authorization for offline backend and online identity server

I am working on a project where the requirement is that:

1. The identity server is online
2. The c# web api backend that has controller actions that require authorization is on a machine that is offline
3. The client (browser) is on a machine that has internet access and is on the same network as the backend

The workflow is something like:

1. Client makes a request to identity server, providing credentials, to obtain a jwt token
2. The jwt token is added as a header to the request that is made to the back end so that it can be authorized

This works well, if I allow the backend machine to have internet access. When I don't allow internet access on the backend machine, the authorization fails. This I believe is because the backend needs to communicate with the identity server to obtain the public key for signing. The public key is obtained from the identity server, at http://identityserver/.well-known/openid-configuration/jwks

I know that I could create a certificate and use that certificate with both the identity server and the back end, but I don't want to do that because once the backend is deployed I have no control over the certificate - if I change the identity server certificate it will break my set up (and also shipping out certificates doesn't sound good).

My idea and thinking:

The http://identityserver/.well-known/openid-configuration/jwks is open to the public and that's the key that the backend needs. The client machine has internet access. Is there any reason why I shouldn't use the client to grab the public key from the identity server end point and put it in a header for my request to the backend that requires authorization (and is offline but on the network)? Then, in the backend, I dynamically set the JwtBearerOptions.TokenValidationParameters.IssuerSigningKey (I am actually using the IssuerSigningKeyResolver to do this) using some middleware I wrote where I parse the header to grab the public signing key. I don't see this approach used anywhere even though there are a number of articles / questions asking about offline authorization.

It is interesting to know why the API server is offline. Sometimes IT administrators do this type of thing, without realising the security and complexity impact.

A better option is for the API server to be online but all external routes blocked by default, eg by some kind of firewall. Then whitelist only the authorization server URL. Security then works in a standard way.

Generally the URL from the API to the JWKS endpoint of the authorization server represents who the API trusts. Do not allow a possibly malicious client to override trust. Eg it would be easy for an attacker to spin up a keypair and send a malicious JWT and public JWK.

Another possible (but more complex) option is to use self-contained JWTs, if your authorization server supports it. This involves deploying a long lived root certificate authority (eg 10 years) from the authorization server with your API.

The JWT header of received access tokens then includes an x5c field including the token signing public key as an X509 certificate. On each request, the API must check that this has the expected name and chains up to its deployed CA before using the received public key to vaidate tokens. This copes reliably with token signing key renewal at the authorization server.