Skip to content

BuildGrid Caches Decoded JWT Token Expiry and Allows Expired Tokens

Context

BuildGrid JWT Authentication allows expired tokens as long as they talk to BuildGrid at least once before they expire since they get cached and we seem to have a slightly off condition on figuring out if we should allow a client to use their token/detecting "expired or not".

If you are raising a bug, please summarise the bug and include:

  • It is expected that: Expired tokens will result in an "expired token" error
  • Current behavior: Expired tokens that have been used at least once with BuildGrid are always allowed (due to BuildGrid's in-memory cache, BuildGrid will correctly identify expired tokens if a client attempts to use them for the first time since BuildGrid's execution after they have expired)
  • Steps to reproduce:
    • Run BuildGrid with JWT Authentication
    • Use a client with a token that expires soon (but hasn't expired yet)
    • ... Wait until the token expires ...
    • Try to use the expired token. BuildGrid will accept it.

Task Description

  • Make sure BuildGrid Authentication Caching logic indeed allows/rejects tokens based on their expiry. ( Looks like the source of the issue is here )
  • If we are using the cache to figure out whether the token expired, we should not be trying to decode again since we should know if it has expired or not! Decoding the same token again should give us the exact same results. (add an else case and return token expired if we have it cached, instead of decoding it again)

Acceptance Criteria

  • Expired Tokens should not be allowed in any case (e.g. first time used with BuildGrid since the bgd server started, used with bgd since it started but token has now expired, etc)
  • Tests to make sure the token caching logic is correct (to catch issues like this in the future)