Understanding the importance of "iat" token claim and troubleshooting the "Invalid issued at time" error
In this post, we are going to explore the importance of the "iat" claim in the ID token and how to troubleshoot the "Invalid issued at time in ID token" error.
Understanding the importance of “iat” token claim and troubleshooting the “Invalid issued at time” error
Background
In our community, every now and then, we hear from our users about this head-scratching issue of “Invalid issued at time in the ID token”. Our users complain that “It was working yesterday but suddenly not working today” or “It works on this computer, but not on the other one”.
In this post, we are going to explore why this issue happens in Logto, and arm you with the know-how to tackle it.
Introduction
In OAuth 2.0 and OpenID Connect (OIDC), ID tokens play an vital role in securely transmitting user identity information between parties. One of the claims in an ID token is called "iat" (issued-at-time), representing the timestamp at which the ID token was issued by the authorization server.
So why is the “iat” claim important?
- Token freshness and expiry: The "iat" claim provides a crucial piece of information for assessing the freshness of an ID token. By comparing the "iat" timestamp with the current time, relying parties can determine how recently the token was issued. This information is valuable for applications that need to ensure the usage of up-to-date identity information.
- Mitigating replay attacks: The "iat" claim plays a vital role in mitigating replay attacks. In a replay attack, an adversary attempts to reuse a previously intercepted token. The "iat" claim helps in detecting such attacks by allowing the relying party to set a tolerance window for the token's age. Tokens outside this window can be considered invalid.
- Enforcing token usage policies: Applications often impose policies on the maximum allowable age of an ID token for security reasons. The "iat" claim enables relying parties to enforce these policies, ensuring that tokens are consumed within a specified timeframe. This helps in minimizing the risk associated with the use of stale tokens.
- Supporting token revocation: In some scenarios, an authorization server might need to revoke issued tokens. The "iat" claim is instrumental in token revocation processes by providing a clear timestamp for when the token was issued. It simplifies the identification and revocation of specific tokens based on their issuance time.
Best practices for handling the “iat” claim
- Validate the "iat" claim: Relying parties should always validate the "iat" claim to ensure that it falls within an acceptable range. This range may vary depending on the specific security requirements of the application.
- Consider clock skew: Allow for a certain degree of clock skew when comparing the "iat" timestamp with the current time. Clock skew accounts for any potential time differences between the authorization server and the relying party.
- Set token expiry policies: Leverage the "iat" claim in conjunction with the "exp" (expiration time) claim to enforce comprehensive token usage policies, enhancing the overall security posture of the application.
Troubleshooting
Now, the root cause of the notorious “Invalid issued at time” error is almost clear.
In order to mitigate replay attacks and also consider the clock skew, Logto previously set a tolerance window of 60 seconds for the ID tokens. Any relying party that has the time difference more than 60 seconds from the world time is considered potentially at risk and will fail the ID token validation. Thus, the “Invalid token at time” error.
However, in real world, clock skew happens, sometimes your computer fails to connect to the world time server to sync the computer time. Sometimes, the authorization server is out-of-sync. Sometimes, even worse, both are out-of-sync.
Moreover, in SSO scenarios, the time differences between various clients and the SSO provider can be even larger.
Solution
In order to mitigate the pain and also considering safety measures, Logto has now increased the iat tolerance from 60 seconds to 5 minutes for non-SSO authentications, and 10 minutes for SSO scenarios.
Meanwhile, you can check if your computer time is synced with the world by simply using this handy tool site: https://time.is Sync your time manually or change to another time server, to make sure the time difference is always within our tolerance window.
Conclusion
The "iat" claim in ID tokens is a crucial element for enhancing the security of identity and access management in modern applications. Incorporating best practices for handling the "iat" claim ensures a robust and secure identity authentication process.
Also make sure your computer time is always synced with the world time server.