60

nbf: Defines the time before which the JWT MUST NOT be accepted for processing

I found this definition about nbf in json web tokens. But still wondering what the usage of nbf is? Why we use this? Does it relate to the term of security?

Any idea would be appreciated.

Vahid Najafi
  • 4,654
  • 11
  • 43
  • 88
  • 1
    The usage is to emit a token that will only be valid after some point in time. Say: you sell a subscription for a service and your customer buys a one hour of use of some resource that starts at `2017-10-10 11:00:00`. So you put the corresponding `nbf` and `exp` and your part of the work is done. – zerkms Apr 08 '17 at 08:04
  • @pvg What do you mean by *just avoid jwt*? – Vahid Najafi Apr 08 '17 at 08:13
  • @zerkms I think your example only consist `exp`. For example, when a trial starts, we have `iat` , then we set some time after `iat` for `exp`. Where is the `nbf` ? – Vahid Najafi Apr 08 '17 at 08:17
  • "and your customer buys a one hour of use of some resource that starts at 2017-10-10 11:00:00". 10th of October 2017 is a date in future (since it is the 8th of April, 2017 today). Their access to the resource starts at that point and lasts for an hour. – zerkms Apr 08 '17 at 08:19
  • @zerkms oh, yes, **starting** in the future is the point. Thank you so much. If you want to right as an answer, I would accept it. – Vahid Najafi Apr 08 '17 at 08:23
  • I mean 'don't use it'. – pvg Apr 08 '17 at 08:30
  • 16
    @pvg an answer without any argument is a useless answer. – noun Jan 03 '18 at 13:53

3 Answers3

110

It definitely is up to how you interpret the time.

One of possible scenarios I could make up is literally - when a token must last from some particular point in time til another point in time.

Say, you're selling some API or resource. And a client purchased access that lasts for one hour and the access starts tomorrow in the midday.

So you issue a JWT with:

  • iat set to now
  • nbf set to tomorrow 12:00pm
  • exp set to tomorrow 1:00pm
zerkms
  • 249,484
  • 69
  • 436
  • 539
  • 4
    "One of possible scenarios I could make up" I'm curious to hear any others. The only purpose I can think of is for issuing tokens that are not valid at the moment of issuing, and the only purpose for that (that I can think of) is exactly what you said: if you sell something that is time-bound and your slot is somewhere in the future. – Luc Jul 30 '19 at 07:56
0

There is one more thing to add what @zerkms told, if you want the token to be used from now, then

nbf also need to be current time(now)

Otherwise you'll get error like the token cannot be used prior to this particular time.

Jopsy
  • 145
  • 1
  • 8
-5

It can be given a time of 3 seconds from time of creation to avoid robots and allow only humans users to access the API.

'nbf' means 'Not Before'.

If nbf=3000, then the token cannot be used before 3 seconds of creation. This makes a brute force attack nearly impossible.

Jasmeet Singh
  • 499
  • 5
  • 6
  • 6
    how this 10s delay prevents from robots? – Andrzej Martyna Sep 21 '17 at 18:03
  • 3
    @AndrzejMartyna It doesn't really prevent anything, per se, but setting a high value can slow down potential attackers trying to get in by way of brute force. –  Dec 22 '17 at 05:54
  • 26
    For future readers: `nbf` should be a NumericDate, not an amount of milliseconds. – IOrlandoni Oct 26 '18 at 15:46
  • 12
    TBH, your scenario is a bit unrealistic. If the attacker needs only "one" token, then 10 seconds waiting is nothing. Note that they know whether they got a valid token or not, regardless of `nbf`. Now if they need more than one token, they can simply build a FIFO queue of thousands of tokens they get, to pay only one "10 second" delay tax, instead of 10s times N delay. Again, they will pay this 10 seconds or whatever, only once, regardless. – Aidin Jun 23 '19 at 01:09
  • 9
    It is not a magic CAPTCHA and this wouldn't prevent any brute force either. This answer makes zero sense in its current or any previous form. – Luc Jul 30 '19 at 07:32
  • As many others have pointed out, this has exactly zero function and benefit against bots. If you are worried about bots, or malicious users, please google "api throttling" to research your real options to proect your API against rapid requests. – Umur Karagöz Mar 13 '22 at 07:42
  • @UmurKaragöz Wouldn't this implement throttling if you add a constraint that each client can only have one valid token at a time? – Brian Hannay Apr 14 '22 at 22:13
  • @BrianHannay Throttling means "how often can I make requests?". This is "How many seconds after logging in can I start making requests?". If you are going to make 1k requests every second, you can very well wait 3 seconds before starting your attack. Again, this has nothing to do with "how often", it is only "when can I start". Hope this is clear enough, you are welcome to ask any additional questions if not. – Umur Karagöz Apr 14 '22 at 22:51
  • @UmurKaragöz In my situation, the token is also invalidated after each use - I didn't mention that. In my case, as far as I can tell given these constraints, the only way for an attacker to send more than one API request per X seconds is if they use more than one "client" - however we identify that. This has nothing to do with `nbf` however. Is there a standardized field to specify a claim is single use? – Brian Hannay Apr 17 '22 at 18:13
  • It looks like I should use the [nonce](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation) field. – Brian Hannay Apr 17 '22 at 18:22
  • This author clearly has used this field to protect against some novice attackers, via the benefit of security through obscurity. – diedthreetimes May 28 '23 at 17:06