3.5.4 - token time-window validation

[elarlang]

Spin-off from #1917

Current requirement:

#	Description	L1	L2	L3	CWE
3.5.4	[ADDED] Verify that stateless tokens are checked for expiration before processing them further.	✓	✓	✓	613

It should be more abstract and cover "time window" when the token is valid.

To check the expiration, we need to require exp to be present and set. It is not set for example for refresh tokens when offline_access is used.

Technically it should also cover to check nbf (Not Before).

Related RFC https://datatracker.ietf.org/doc/html/rfc7519

• exp - optional
• nbf - optional

So the requirement need to validate the "time-window", and it can be validated, if nbf and/or exp claims are provided in the token (both are optional).

[elarlang]

Something like that?

Verify that stateless token is allowed to be used at the time of checking, using not-before ('nbf' claim in JWT) and expires ('exp' claim in JWT) values, if those are provided in the token.

[randomstuff]

For reference some wording about "iat" and "nbf" (but not "exp") from FAPI 2.0:

to accommodate clock offsets, shall accept JWTs with an iat or nbf timestamp between 0 and 10 seconds in the future but shall reject JWTs with an iat or nbf timestamp greater than 60 seconds in the future.

[elarlang]

I would not put iat here that quickly. From this you can assume are the clocks synced, but it is not meant for time-window validation.

[randomstuff]

I would not put iat here that quickly. From this you can assume are the clocks synced, but it is not meant for time-window validation.

Note that for DPoP, "iat" is the value used to check the validity of the DPoP proof.

Verify that stateless token is allowed to be used at the time of checking, using not-before ('nbf' claim in JWT) and expires ('exp' claim in JWT) values, if those are provided in the token.

I'm wondering if there is something missing here (?):

• it is the consumer of the token which must verify that the token is allowed to be used […]
• and we must verify that the consumer of the token verifies that the token is allowed to be used.

So this should be something like:

Verify the the consumer of a stateless token verifies that stateless token is allowed to be used at the time of checking, using not-before ('nbf' claim in JWT) and expires ('exp' claim in JWT) values, if those are provided in the token.

[randomstuff]

What about something like:

Verify that the consumer of a stateless token accepts the token only if the verification time is within this validity time span in the token (if present). For example, for JWTs, this is typically conveyed using the 'nbf' and 'exp' claims.

or

Verify that the consumer of a stateless tokens honors the validity time span associated with the token (if present). For example, for JWTs, this is typically conveyed using the 'nbf' and 'exp' claims.

[elarlang]

From last 2 proposals I prefer the first one. This "honors" feels a bit out of context, we need to use a strong and clear term such as "must" from https://datatracker.ietf.org/doc/html/rfc2119.

(if present) feels like it is written for the token "if token is present", I think it should be repositioned to be clearly apply to time-window claims.

consumer - it can be there, but I think it is not necessary. If something is going to use the content from the token, is is consuming the content and is consumer by nature. Is there any other interpretation that we need to clarify this?

[elarlang]

Rechecking it again, I think this one good enough:

Verify the the consumer of a stateless token verifies that stateless token is allowed to be used at the time of checking, using not-before ('nbf' claim in JWT) and expires ('exp' claim in JWT) values, if those are provided in the token.

@randomstuff - any changes or improvement to apply from your last proposal comment taking into account my last comment?

[elarlang]

Some more versions:

• Verify that the stateless token is allowed to be used at the time of checking, using not-before ('nbf' claim in JWT) and expires ('exp' claim in JWT) values, if those are provided in the token.
• Verify that if the stateless token has information about the time of being valid, such as 'nbf' and 'exp' claims in JWT, the consumer validates if the token is allowed to be used at the time of checking.
• Verify that the stateless token is allowed to be used at the time of checking if the stateless token has information about the time of being valid, such as 'nbf' and 'exp' claims in JWT.

[randomstuff]

I'd like your second version better. The two other looks somewhat ambiguous to me.

Analysis of the third proposition

For example,

Verify that the stateless token is allowed to be used at the time of checking if the stateless token has information about the time of being valid, such as 'nbf' and 'exp' claims in JWT.

I think this is ambiguous about the scope of the condition. This might be understood as:

Verify that the (stateless token is allowed to be used at the time of checking if the stateless token has information about the time of being valid), such as 'nbf' and 'exp' claims in JWT.

whereas we mean:

(Verify that the stateless token is allowed to be used at the time of checking) if the stateless token has information about the time of being valid, such as 'nbf' and 'exp' claims in JWT.

This would be clearer:

Verify, if the stateless token has information about the time of being valid (such as 'nbf' and 'exp' claims in JWT), the stateless token is allowed to be used at the time of checking.

But actually, something seems to be missing to me and we mean:

Verify, if the stateless token has information about the time of being valid (such as 'nbf' and 'exp' claims in JWT), the application verifies the token is currently valid according to this information before taking any actions based on this token.

What about:

Verify that application accepts an stateless token only if the verification time is within this validity time span in the token, if such a validity time span is present. For JWTs and OAuth Token Introspection, this is currently represented by the 'nbf' and 'exp' claims and properties respectively.

or

Verify, if a stateless token is associated with some validity time span, the application verifies the token is currently valid according to this information before taking any action based on this token. For JWTs and OAuth Token Introspection, this is currently represented by the 'nbf' and 'exp' claims and properties respectively.

I removed "stateless" here because this can apply to stateful tokens as well (i.e. when using OAuth token introspection), right?

[ryarmst]

May I suggest wording that favours rejection over acceptance? For example, rather than "accepts a token only if.." what about "rejects the token if..."?

[elarlang]

I'm a bit lost now what is the latest proposal here :)

@randomstuff - just in case, it is a V3 issue. If we want to have OAuth mentioned, it sounds like a specific requirement for V51. By content at the moment I see it as general requirement.

Is OAuth Introspection defines nbf and exp or it uses the definitions from JWT?

[randomstuff]

@elarlang, the token introspection part can be skipped if needed.

The definitions of nbf and exp from token introspection reference the definition from JWT (but use them in a separate context):

exp OPTIONAL. Integer timestamp, measured in the number of seconds since January 1 1970 UTC, indicating when this token will expire, as defined in JWT [RFC7519].

[...]

nbf OPTIONAL. Integer timestamp, measured in the number of seconds since January 1 1970 UTC, indicating when this token is not to be used before, as defined in JWT [RFC7519].

[elarlang]

Those definitions I referenced in the issue description.

My point here is that we should make "in general" valid requirements for (JWT) tokens. If there is a more specific case to cover with some specific, then there is a need to make a separate requirement for the related paragraph.

[TobiasAhnoff]

A suggestion, as part of This is part of "cleaning up 3.5" see #1917 (comment), is to have:

Verify that the token is valid based on current time and, if present, the token identifier. For JWTs the claims 'iat', 'nbf' and 'exp' should be verified for time based validation. The claim 'jti' should be validated to identify a specific token, in example to assert that the token is only used once.

[randomstuff]

The claim 'jti' should be validated to identify a specific token, in example to assert that the token is only used once.

I would not include this. It's usually OK to use your access token many times while it's still valid.

Some tokens are supposed to be used only once (ID token, DPoP proofs) but this is not the case for all tokens (such as access tokens).

[elarlang]

The claim 'jti' should be validated to identify a specific token, in example to assert that the token is only used once.

This is a separate test and problem to solve. Let this requirement only focus on the time window.

I would like the second part / example as it is:

For JWTs the claims 'iat', 'nbf' and 'exp' should be verified for time based validation.

But I did not find any solution for first part that I'm happy with. For a starter:

Verify that the token and it's content are accepted only if the verification time is within this validity time span in the token if such a validity time span is present in the token data.

[TobiasAhnoff]

This is a separate test and problem to solve. Let this requirement only focus on the time window.

I agree, good to split this.

But I did not find any solution for first part that I'm happy with.

Is this better?

Verify that, if validity time span is present in the token data, the token and it's content are accepted only if the verification time is within this validity time span. For JWTs the claims 'iat', 'nbf' and 'exp' should be verified.

[elarlang]

Some changes, including removed 'iat' claim, as it is not meant for time-window validation by JWT own spec. It can be used if the application logic works that way and the requirement is still valid for "validity must be checked" and for example, for JWT those claims must (I changed should to must) be used:

Verify that, if a validity time span is present in the token data, the token and it's content are accepted only if the verification time is within this validity time span. For example, for JWTs the claims 'nbf' and 'exp' must be verified.