`isExpired` doesn't correctly validate `iat`

[ppamorim]

Checklist

• I have looked into the Readme and Examples, and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

Due to the way the isExpired was implemented, the iat is invalid for the first 0.5 seconds of JWT existence, given this code here:

JWTDecode.Android/lib/src/main/java/com/auth0/android/jwt/JWT.java

Lines 161 to 171 in df3eb30

	public boolean isExpired(long leeway) {
	if (leeway < 0) {
	throw new IllegalArgumentException("The leeway must be a positive value.");
	}
	long todayTime = (long) (Math.floor(new Date().getTime() / 1000) * 1000); //truncate millis
	Date futureToday = new Date(todayTime + leeway * 1000);
	Date pastToday = new Date(todayTime - leeway * 1000);
	boolean expValid = payload.exp == null || !pastToday.after(payload.exp);
	boolean iatValid = payload.iat == null || !futureToday.before(payload.iat);
	return !expValid || !iatValid;
	}

The line 165 is rounding the current time. If your server is very fast and generate, transmit and reaches your application in less than 0.5s, the futureToday.before(payload.iat) on the line 169 returns false. But the JWT is totally valid.

Solutions:

• Also compare futureToday == payload.iat.
• Stop truncating the todayTime.

I reimplemented the validation in Kotlin and added some logs:

fun isExpired(jwt: JWT, leeway: Int): Boolean {
  val todayTime = (floor((Date().time / 1000).toDouble()) * 1000).toLong() //truncate millis
  val futureToday = Date(todayTime + leeway * 1000)
  val pastToday = Date(todayTime - leeway * 1000)
  val expValid = jwt.expiresAt == null || !pastToday.after(jwt.expiresAt)
  val iatValid = jwt.issuedAt == null || !futureToday.before(jwt.issuedAt)
  return !expValid || !iatValid
}

This prints:

todayTime 1740576730000
futureToday 1740576730000
pastToday 1740576730000
expValid true
iatValid false

Reproduction

Probably create the JWT and use it straightway, it will fail on the iat.

Additional context

No response

JWTDecode.Android version

2.0.2

Android version(s)

API 32

[ppamorim]

I am using internally a extension of the isExpired function that contains a fix and has a more dynamic leeway:

data class ExpireConfig(val leewayIat: Int, val leewayExp: Int)

/**
 * Determines whether the given JWT is expired.
 *
 * This function checks the expiration and issued-at times of the JWT, taking into account a
 * specified leeway (in seconds) to accommodate possible clock skew. The JWT is considered expired
 * if either:
 * - The expiration time is missing or the current time exceeds the expiration time by more
 *   than the leeway.
 * - The issued-at time is missing or the current time is earlier than the issued-at time
 *   minus the leeway.
 *
 * @param config The allowed leeway (in seconds) to adjust for clock skew.
 * @return `true` if the JWT is expired; otherwise, `false`.
 */
fun JWT.isExpiredFixed(config: ExpireConfig): Boolean {
  // If the token does not have an expiration time, consider it expired.
  val expiresAt = this.expiresAt ?: return true
  // If the token does not have an issued-at time, consider it expired.
  val issuedAt = this.issuedAt ?: return true
  // Get the current system time in milliseconds.
  val now = System.currentTimeMillis()
  val leewayIatMillis = config.leewayIat * 1000
  val leewayExpMillis = config.leewayExp * 1000
  // Check if the token has expired. The token is considered expired if the current time minus the
  // leeway (converted to milliseconds) is greater than the expiration time.
  if (now - leewayExpMillis > expiresAt.time) {
    return true
  }
  // Validate the issued-at time. The token is considered invalid if the current time plus the
  // leeway (converted to milliseconds) is less than the issued-at time.
  return now + leewayIatMillis < issuedAt.time
}

In practice, a longer iat duration is not an issue on the client side. For my case, I set the iat leeway to 30 seconds (also because my device had a skew in the current time) and the exp leeway to -5 seconds. This ensures the client considers the token expired slightly earlier, preventing unnecessary server calls with a JWT that is about to expire around the expiration timeframe.

[pmathew92]

Hi @ppamorim , Thank you for bringing this to our notice. Will take a look into this

[cj-marius-duna]

The isExpired code has issues. Here is a cleaner version:

public boolean isExpired(long leeway) {
    if (leeway < 0) {
        throw new IllegalArgumentException("The leeway must be a positive value.");
    }

    long nowMillis = System.currentTimeMillis();
    Date now = new Date(nowMillis);
    Date expLeeway = new Date(nowMillis - leeway * 1000); // Accept some leeway after expiry
    Date iatLeeway = new Date(nowMillis + leeway * 1000); // Accept a bit of skew in issuedAt

    boolean expValid = payload.exp == null || payload.exp.after(expLeeway);
    boolean iatValid = payload.iat == null || !payload.iat.after(iatLeeway);

    return !expValid || !iatValid;
}

[pmathew92]

Hi @cj-marius-duna , would you like to raise this as a PR? We would be happy to review it

[ppamorim]

The isExpired code has issues. Here is a cleaner version:

public boolean isExpired(long leeway) {
    if (leeway < 0) {
        throw new IllegalArgumentException("The leeway must be a positive value.");
    }

    long nowMillis = System.currentTimeMillis();
    Date now = new Date(nowMillis);
    Date expLeeway = new Date(nowMillis - leeway * 1000); // Accept some leeway after expiry
    Date iatLeeway = new Date(nowMillis + leeway * 1000); // Accept a bit of skew in issuedAt

    boolean expValid = payload.exp == null || payload.exp.after(expLeeway);
    boolean iatValid = payload.iat == null || !payload.iat.after(iatLeeway);

    return !expValid || !iatValid;
}

I don't see any benefit or reason to not let the leeway to be negative, there is a use case for that.

[nicbell]

The method didn't event make sense to me, I want the leeway to be negative as I want to proactively refresh tokens.

[cj-marius-duna]

I agree we should remove

    if (leeway < 0) {
        throw new IllegalArgumentException("The leeway must be a positive value.");
    }

this way we can refresh the token earlier

[cj-marius-duna]

I cannot push a new branch to create PR...

[pmathew92]

Hi @cj-marius-duna , what error are you observing ? Is it when you are raising PR from your fork repo ?