Handling Access Token Refusals Due to Time Discrepancies

[aldbr]

We've encountered an issue where some access tokens are occasionally rejected by the Computing Elements (CEs). The primary error observed on the CE side is shown below:

[2024-01-29 10:43:53] [Arc.JWSE] [DEBUG] [20077/6] JWSE::Input: JWS content: {
        ...
        "nbf":  1706521434,  // Mon Jan 29 2024 10:43:54 GMT+0100
        ...
}
[2024-01-29 10:43:53] [Arc.JWSE] [DEBUG] [20077/6] JWSE::Input: JWS: token too young
...
[2024-01-29 10:43:53] [Arc.MCC.HTTP] [WARNING] [20077/6] HTTP Error: 403 User can't be assigned configuration

The error, "token too young", indicates a problem with the nbf (Not Before) claim. It appears the CE's current time (2024-01-29 10:43:53) is slightly behind the nbf time of the token (1706521434 = Mon Jan 29 2024 10:43:54 GMT+0100).

Further evidence of time discrepancy is observed in the CE's logs:

[2024-01-29 10:22:01] [Arc.validator] [WARNING] Timecheck: Your time differs slightly (1.604302 seconds) from the public time server 'europe.pool.ntp.org'.

Although the root cause lies with the time synchronization on the CE side, we propose a pragmatic solution to enhance the robustness of our system: configuring a small leeway in the nbf claim of the access tokens. This approach aligns with the guidelines in the JWT RFC (https://www.rfc-editor.org/rfc/rfc7519#section-4.1.5), which states:

Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew.

By introducing this leeway, we aim to mitigate token rejection issues stemming from minor time differences without compromising security.

We're keen to hear thoughts and feedback on this approach, particularly concerning best practices and potential implications.

[Roberta Miccoli]

Hi, which Indigo IAM instance are you using?
Note that there is a possibility of not including the nbf claim in the access token through this env variable IAM_ACCESS_TOKEN_INCLUDE_NBF=false (ref: https://indigo-iam.github.io/v/v1.8.3/docs/reference/configuration/#access-token-contents-configuration)

[Maarten Litmaath]

Hi all,
I think it would be fine to make the value of nbf the current time minus a few minutes, which would need to be made configurable and have a reasonable default, e.g. 300 seconds.

We can try omitting that claim: hopefully all relevant MW considers it optional indeed...

[aldbr]

Hi, which Indigo IAM instance are you using? Note that there is a possibility of not including the nbf claim in the access token through this env variable IAM_ACCESS_TOKEN_INCLUDE_NBF=false (ref: https://indigo-iam.github.io/v/v1.8.3/docs/reference/configuration/#access-token-contents-configuration)

We are using the LHCb IAM instance, so the WLCG token profile. Theoretically, the nbf claim should be optional so we should be able to safely disable it. We will give this a try, thanks!