In theory, you can issue a token that only becomes valid in the future. That would have a different iat and nbf timestamp. I have not seen this in practice though.
Given that RFC 7519 lists “iat” as informative, I would not change that behavior in a specific use case if there is no significant need to do so. Philippe > On 20 Apr 2020, at 08:50, Dominick Baier <[email protected]> wrote: > > Just a quick data point - > > The Microsoft .NET JWT implementation checks for exp and nbf. Not iat. > > I guess my real question is - what’s the difference between the two > practically speaking - and shouldn’t be the more common (aka supported by > most libraries) be used? > > ——— > Dominick Baier > > On 20. April 2020 at 06:59:47, David Waite > ([email protected] > <mailto:[email protected]>) wrote: > >> There are a number of ambiguities and statements around using JWTs in >> various contexts: >> >> 1. Some implementations interpret “iat" to also have the meaning of “nbf” in >> the absence of “nbf”, although this is AFAIK not prescribed by any spec >> 2. The DPoP draft’s client-generated tokens have the resource servers use >> their own nbf/exp heuristics around “iat”, since the tokens are meant for >> immediate one time use by a party that may not have clock synchronization. >> 3. There are recommendations in the JWT profile for OAuth that the AS may >> reject tokens based on an “iat” too far in the past or “exp” too far in the >> future, but not that “nbf” was too far in the past or that the interval >> between nbf and exp was too large. >> >> The JWT spec also allows implementers to provide some leeway for clock skew. >> Presumably this meant validators and not JWT creators, although there is >> history of messages setting similar values to account for clock skew (e.g. >> SAML IDPs setting notBefore to one minute before issuance and notOnOrAfter 5 >> minutes after issuance). >> >> -DW >> >>> On Apr 19, 2020, at 2:50 AM, Vladimir Dzhuvinov <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> On 16/04/2020 10:10, Dominick Baier wrote: >>>> iat vs nbf >>>> What’s the rationale for using iat instead of nbf. Aren’t most JWT >>>> libraries (including e.g. the ..NET one) looking for nbf by default? >>> Developers often tend to intuitively pick up "iat" over "nbf" because it >>> sounds more meaningful (my private observation). So given the empirical >>> approach of Vittorio to the spec, I suspect that's how "iat" got here. >>> >>> If we bother to carefully look at the JWT spec we'll see that "iat" is >>> meant to be "informational" whereas it's "nbf" that is intended to serve >>> (together with "exp") in determining the actual validity window of the JWT. >>> >>> https://tools.ietf.org/html/rfc7519#section-4.1.5 >>> <https://tools.ietf.org/html/rfc7519#section-4.1.5> >>> My suggestion is to require either "iat" or "nbf". That shouldn't break >>> anything, and deployments that rely on one or the other to determine the >>> validity window of the access token can continue using their preferred >>> claim for that. >>> >>> Vladimir >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > _______________________________________________ > OAuth mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
