Narrative

The https://en.wikipedia.org/wiki/Year_2038_problem states that a 4 byte integer can't store a timestamp beyond 2038, and that it would need to be 8 bytes long for tha. 

Keycloak has several places where it handles the current time and the expiration time as an integer. This prevents a current time after 2038, and also expiry dates after 2038.

https://github.com/keycloak/keycloak/blob/10ccc439e4950a331e1ad9f9f8c7d7442c881b63/common/src/main/java/org/keycloak/common/util/Time.java#L33-L35 

Some methods in JsonWebToken are deprecated as they return an integer, but they are still used in lots of places. Currently Time.currentTime() still returns an integer.

This leads to problems when session timeouts are calculated for longer than a 10 year range. In that situations tokens are treated as outdated, and you might even break your Keycloak setup. 

Value Proposition

Given that the Keycloak 27 would appear in 2026 with a support range of 3 years, this is a breaking change that should be in this release to ensure that 10 year token lifetimes are possible. 

Goals

• Allow token expiry longer than 2038.
• Clean up deprecated methods.
• Change all internal APIs to use a long to represent the seconds since 1970. 

Non-Goals

• Use a different datatype than long to handle time and duration. Still after the change it will be tricky to distinguish between millisecond timestamp and second timestamp as they both will be longs after the change. 

Related issues

Contains all the various issues/bugs reported, which are related to this problem:

• High values for client secret expiration result in expiration dates in the past #38124