Better control over expiration and IssuedAtOffset for grace periods

[EthanHeilman]

Preflight Checklist

• I could not find a solution in the existing issues, docs, nor discussions
• I have joined the ZITADEL chat

Describe your problem

I'm running into an issue where ID Tokens are set to expiry is 30 seconds after issuedAt, but client's have 1 minute random clock skew. This means that sometimes issuedAt from the client's perspective be 1 minue in the future. I fixed the clock skew issue by setting an IssuedAtOffset of 1 minute. The problem is this offset is also used for expiry, so that if expiry <= (issuedAt + 1 minute) the ID Token fails as expired.

These both share the same offset:

if err = oidc.CheckExpiration(claims, v.Offset); err != nil {
    return nilClaims, err
}

if err = oidc.CheckIssuedAt(claims, v.MaxAgeIAT, v.Offset); err != nil {
    return nilClaims, err
}

Originally reported here: openpubkey/openpubkey#313

Describe your ideal solution

Possible solutions:

• Allow these offsets to be independently specified. Maybe a clock skew grace period option.
• Allow the ability to disable expiration check so that dependent software can handle the expiration itself. This is less likely to be a foodgun because the implementor must be explicit about their intention.
  Inject my own NewIDTokenVerifier into the RP, is this possible?

Version

v3.23.2

Additional Context

I'd be willing to open a PR for this, if there is interest.

[hifabienne]

In the token settings of the application, you have the possibility to set the clock skew did you try that already?

[EthanHeilman]

@hifabienne Which application? I don't control the OP client console. I can not tell the OP to add clock skew, I don't even control what OPs will be used.

I am just writing software that manages ID Tokens using the zitadel/oidc as a library for requesting ID Tokens.

[hifabienne]

@hifabienne Which application? I don't control the OP client console. I can not tell the OP to add clock skew, I don't even control what OPs will be used.

I am just writing software that manages ID Tokens using the zitadel/oidc as a library for requesting ID Tokens.

Hi @EthanHeilman Sorry, i missed that this issue was added in the oidc repository, and not in our main zitadel repository.
@livio-a @muhlemmer can you help here?

[EthanHeilman]

Pinging on this

[muhlemmer]

I think your usecase is somewhat in the extreme and unrealistic. Why would you want such a short (30 second) validity for the ID token? It is a local credential at the web-app that is never shared beyond that point. Second, why "random clock skew" of one minute? Use NTP to make sure your clocks are in sync and you don't have this problem.

Allow the ability to disable expiration check so that dependent software can handle the expiration itself. This is less likely to be a foodgun because the implementor must be explicit about their intention.
Inject my own NewIDTokenVerifier into the RP, is this possible?

We wouldn't want to offer that flexibility. The standard is pretty strict we should handle expiry:

exp
REQUIRED. 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. Its value is a JSON [RFC8259] number representing the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular. NOTE: The ID Token expiration time is unrelated the lifetime of the authenticated session between the RP and the OP.

Allow these offsets to be independently specified. Maybe a clock skew grace period option.

Skew is allowed and workable. Please note that we release using Semver, so a PR should not break / remove the Offset setting, but instead deal with both variants depending on which was set.

If you can properly manage that, we are open for a PR.

[EthanHeilman]

I think your usecase is somewhat in the extreme and unrealistic. Why would you want such a short (30 second) validity for the ID token?

I was as surprised as your are, but this is default at some OpenID Providers. Users bring their own OPs and I want things to work out of the box.

It is a local credential at the web-app that is never shared beyond that point. Second, why "random clock skew" of one minute? Use NTP to make sure your clocks are in sync and you don't have this problem.

It is a issue I've run into personally on stock OSX macbooks running NTP and issues users have run into. My experience has been NTP is not reliable to within a minute.

Skew is allowed and workable. Please note that we release using Semver, so a PR should not break / remove the Offset setting, but instead deal with both variants depending on which was set.

Thanks, I'll put a PR together over the next week. Do you have an example of similar PR to this project that handled Semver well?