[Bug] client assetion is not within valid time range.

[sudoapt-getclean]

Library version used

v1.23.0

Java version

23

Scenario

ConfidentialClient - service to service (AcquireTokenForClient)

Is this a new or an existing app?

The app is in production, and I have upgraded to a new version of MSAL

Issue description and reproduction steps

Hi,
1 hour afte we upgrade to msal v1.23.0 we started seeing this stacktrace:

Caused by: com.microsoft.aad.msal4j.MsalServiceException: AADSTS700024: Client assertion is not within its valid time range. Current time: 2025-08-29T05:47:32.1501147Z, assertion valid from 1970-01-01T00:00:00.0000000Z, expiry time of assertion 2025-08-29T00:30:05.0000000Z. Review the documentation at https://learn.microsoft.com/entra/identity-platform/certificate-credentials . Trace ID: 7a84b74b-1889-494f-b408-66e8b36c7400 Correlation ID: d75bd923-d9ca-4d18-b80e-b13851840fa9 Timestamp: 2025-08-29 05:47:32Z
	at com.microsoft.aad.msal4j.MsalServiceExceptionFactory.fromHttpResponse(MsalServiceExceptionFactory.java:38)
	at com.microsoft.aad.msal4j.TokenRequestExecutor.createAuthenticationResultFromOauthHttpResponse(TokenRequestExecutor.java:168)
	at com.microsoft.aad.msal4j.TokenRequestExecutor.executeTokenRequest(TokenRequestExecutor.java:35)
	at com.microsoft.aad.msal4j.AbstractApplicationBase.acquireTokenCommon(AbstractApplicationBase.java:75)
	at com.microsoft.aad.msal4j.AcquireTokenByAuthorizationGrantSupplier.execute(AcquireTokenByAuthorizationGrantSupplier.java:60)
	at com.microsoft.aad.msal4j.AcquireTokenByClientCredentialSupplier.acquireTokenByClientCredential(AcquireTokenByClientCredentialSupplier.java:87)
	at com.microsoft.aad.msal4j.AcquireTokenByClientCredentialSupplier.execute(AcquireTokenByClientCredentialSupplier.java:50)
	at com.microsoft.aad.msal4j.AuthenticationResultSupplier.get(AuthenticationResultSupplier.java:69)
	at com.microsoft.aad.msal4j.AuthenticationResultSupplier.get(AuthenticationResultSupplier.java:18)
	at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768)

and msal was nog longer able to aquire authenitcation tokens

Relevant code snippets

class AzureADTokenFromCertificateProvider(
  url: String,
  clientId: String,
  rsaPrivateKey: String,
  rsaCertificate: String,
  scope: String
) {

  private val app: ConfidentialClientApplication
  private val clientCredentialParam: ClientCredentialParameters

  init {
    val keyFactory = KeyFactory.getInstance("RSA")
    val pkcs8KeySpec = PKCS8EncodedKeySpec(Base64.getDecoder().decode(rsaPrivateKey))
    val privateKey = keyFactory.generatePrivate(pkcs8KeySpec)

    val certificateFactory = CertificateFactory.getInstance("X.509")
    val x509Stream = ByteArrayInputStream(Base64.getDecoder().decode(rsaCertificate))
    val certificate = certificateFactory.generateCertificate(x509Stream) as X509Certificate

    app = ConfidentialClientApplication
      .builder(clientId, ClientCredentialFactory.createFromCertificate(privateKey, certificate))
      .authority(url)
      .build()

    clientCredentialParam = ClientCredentialParameters
      .builder(setOf(scope))
      .build()
  }

  fun accessToken(): String {
    return app.acquireToken(clientCredentialParam).get().accessToken()
  }
}

Expected behavior

aquire tokens like before

Identity provider

Microsoft Entra ID (Work and School accounts and Personal Microsoft accounts)

Regression

1.22

Solution and workarounds

none found

[Avery-Dunn]

Hello @sudoapt-getclean : In 1.23.0 we did a big refactor to remove third-party dependencies so this definitely could be a regression, however I don't think assertions were affected in a major way and I'm unable to reproduce your issue locally.

The only way I could get that "AADSTS700024: Client assertion is not within its valid time range..." error is by going into JwtHelper and manually changing the "exp" value to something invalid.

That class was refactored to remove the usage of in com.nimbusds.jwt in this PR, but I don't think that would be causing your issue for two reasons:

• Even when using com.nimbusds.jwt we were still basing the values off of the current system time, that aspect hasn't changed
• The "expiry time of assertion 2025-08-29T00:30:05" in the error message is directly based of the exp value set in JwtHelper, but that value doesn't make sense: we calculate exp based on "current time + 10 minutes", but the expiry time in your error isn't cleanly offset by 10 minutes or or cleanly offset by any timezone compared to "Current time: 2025-08-29T05:47:32"

My only guess is that an assertion is being cached somewhere or you're overriding the assertion creation, but I have no idea how either of those could be happening.

You mentioned the app is in production, did you also see this issue in a test environment? Also, could you debug your code and confirm the following:

1. The expiry value in the JWT assertion made by JwtHelper
2. The expiry value in the JWT assertion sent to the endpoint (likely in the body of the httpRequest in DefaultHttpClient.send(HttpRequest httpRequest))

[sudoapt-getclean]

I'm still looking into a proper way I can do debugging for inside openshift/kubernetes environment.
An interesting observation that I still want to share is that the expiration time I see in the logs is pinned for a specific run of that application. So the applications keeps on sending exactly the same value for the exp in every request.
That value is ±51 minutes after the initial start of the application.
I've looked through the code and some theories I have is that JsonProviders.createReader(jsonResponse) somehow returns a static response, or the input it gets is always the same which would mean that HttpResponse oauthHttpResponse = oAuthHttpRequest.send(); is not working as expected.

[Avery-Dunn]

In this PR a lot of behavior was changed related to how the assertion was made per-application and how it was used per-request: #927

Long story short the old code had a mechanism to refresh the assertion built into some of ConfidentialClientApplication's methods which I believe was also handled elsewhere, but maybe all of the assertion's refresh behavior was lost in various refactors? I'll need to investigate more and confirm but if that's the root cause we'll definitely be able to get a hotfix out this week.

It wouldn't explain why the expiry time is 51 minutes away from the start of the application (I would've expected 10 minutes), but it would explain why an application would have the same expiry time on every request.

Though just to clarify: when you say the expiry time is "pinned for a specific run of that application", do you mean every instance of a ConfidentialClientApplication you has its own expiry time, but it's always about 50 minutes away from when that instance got made? Or do you mean even when you fully restart everything and make a new ConfidentialClientApplication the expiry time is tied to a single old run?

[sudoapt-getclean]

Hi Avery,
i've stepped through the code with the debugger
and I'm pretty sure I have narrowed things down to this line of code:

microsoft-authentication-library-for-java/msal4j-sdk/src/main/java/com/microsoft/aad/msal4j/TokenRequestExecutor.java

Line 97 in dfae289

addJWTBearerAssertionParams(queryParameters, ((ConfidentialClientApplication) msalRequest.application()).assertion);

this line retrieves an assertion String from the ConfidentialClientApplication previously this string was recreated on separate runs but with the current code it is only generated during the init() of the clientApplication
since the string contains the exp that will not be updated anymore and the authentication breaks when the exp is no longer in the future

[Avery-Dunn]

That definitely seemed be the root cause: rather that directly getting the assertion field, there used to be a getter method which checked the expiry time before returning the string. The refresh behavior was dropped in a refactor and never properly replaced.

I've created a PR to essentially re-add the behavior that existed prior to 1.23.0 and ensure the assertion is refreshed when it expires: #986

We should be able to get a hotfix out this week, thanks for all the help with this!