0

I have a question about the "best practice" of refreshing jwks data.

A customer has an java spring web intranet application with very strict network settings. So, the webserver is not allowed to make requests into the internet.

We must implement a SSO solution with MS Azure. So, we import the well-known openid configuration and import the data from the jwks_uri. Initially this is not a problem. So, the SSO login works - but only till the keys in the jwks_uri changes.

But how should we update the content from the jwks_uri? The server is not allowed to access this internet resource.

As I have understood this, normally we should reload this data on a daily base. The content of the jwks_uri could change.

Is there a best practice for such a setup? Or must I convince the security team to allow the server to access this two Microsoft URLs?

enter image description here

In the configuration of this SSO solution, the administrator fetches the wellknown openid configuration and the content from the jwks_uri and pastes the content to the intranet application admin interface. So, the intranet server knows the public keys from the MS Azure service and can validate the signature of the id_tokens.

But this keys changes from time to time on MS Azure side. So, is there a best practice for this how the intranet application comes to the new public keys? Is there any "magic" I do not know?

Sidadl
  • 21
  • 2

1 Answers1

0

You should allow the services that depend on AzureAD to also be able to communicate with them. Otherwise, you can't for example

  • get the tokens if you are using the authorization code flow.
  • use the refresh tokens to get a new access token

I don't see how you can get it to work if the services both public and internally can't talk directly to AzureAD.

However, there is one alternative and that is to have a local token service (IdentityServer, Keycloak...) to proxy between your local services and the public internet.

enter image description here

In general your services should only trust one token issuer.

The alternative is to provide the keys manually, for example by setting:

.AddJwtBearer("MyScheme", options =>
{
    var key = Encoding.UTF8.GetBytes(Configuration["JwtConfig:AccessTokenSecret"]);

    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuerSigningKey = true, 
        IssuerSigningKey = new SymmetricSecurityKey(key), 
        ...
    ...
};

See sample answer here How to set Dynamic IssuerSigningKey and TokenDecryptionKey in AddJwtBearer options in ConfigureServices method on Startup.cs file

Tore Nestenius
  • 16,431
  • 5
  • 30
  • 40
  • The client is not the problem. The client has full internet access. So fetching the token from Azure is not the problem. But the server, which hosts the configuration has no internet access. So, the server cannot fetch the jwks_uri to fetch new certificates or public keys to check the id_token signature. – Sidadl Dec 25 '22 at 19:57