the iat claim and clock skew issues

[Andrii Deinega]

The ID Token section of the OpenID Connect Core 1.0 (errata set 2) spec describes the exp claim in the following way

Expiration time on or after which the ID Token MUST NOT be accepted by the RP when performing authentication with the OP. The processing of this parameter requires that the current date/time MUST be before the expiration date/time listed in the value. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew.

At the same time, the description for iat claim does not say anything specific about whether the ID Token should be accepted or rejected by an RP when it gets issued in the “near“ future from its point of view (this might happen when an RP runs into time skew issues).

I suggest clarifying these things a bit, quick research uncovered that different OpenID Connect libraries cover that in different ways (some of them take into account small leeway for time in both iat and exp claims, others only for time in the exp claim and so forth).

[Joseph Heenan]

For what it’s worth the conformance suite:

1. will fail if iat is in the future (allowing for 5 minutes clock skew)
2. will fail if iat is more than 5 minutes in the past

The latter is based on this text from the spec:

"The iat Claim can be used to reject tokens that were issued too far away from the current time, limiting
the amount of time that nonces need to be stored to prevent attacks. The acceptable range is Client specific."

(I’m not necessarily suggesting other clients should behave in this way, but people often ask what the certification tests check when discussing issues like this,)

[Brian Campbell]

maybe worth nothing that there was a thread on the same or similar subject on the OAuth WG list a few months ago:

https://mailarchive.ietf.org/arch/msg/oauth/Qkz2HqOzdVM0oyDPSeOdo-iLN8E/

‌

[Nat Sakimura]

Opened the ticket on the June 17 call. As Brian points out, this is more or less the same issue as the one discussed in the OAuth group, and the callers thought we should not be doing anything different than that.

[Andrii Deinega]

The reason I filled this one is that, is that we had a very minor disagreement as of how to validate idTokens issued in the near future, and when we came to double check that in the core spec, we quickly learned that that isn’t actually specified.

Brian is right, there was a discussion in the OAuth WG started after https://www.rfc-editor.org/errata/eid7720.

An interesting fact about the core spec is that there is no mention about the nbf claim in the whole spec, and in https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims in particular.

[Nat Sakimura]

1. Whether to add nbf in ID Token,
2. and/or write some text on clock skew for iat?

‌

[Michael Jones]

“nbf” isn’t present because it’s not used in ID Tokens as defined and not part of the validation logic. Therefore, omitting it is correct.

If we add text on allowing for clock skew for “iat”, I believe the place to add it would be in step 10 of https://openid.net/specs/openid-connect-core-1_0-errata2.html#IDTokenValidation . If we do that, we should probably also explicitly allow for clock skew in step 9 (use of “exp”).

[Filip Skokan]

There is no need for iat skew to be mentioned because iat has no “future” or “past” validation defined based on the current timestamp. Ergo, skew in the iat is not generally a cause for rejection when claims like exp or nbf are present (which is the case here - exp is a required claim)