Add model for JWT refresh token

[stveit]

Adds a model representing a JWT refresh token. Contains a hash of the real token. Refresh tokens can then effectively be authenticated by comparing the hash to incoming token to hashes in the database.

The model contains relevant information about the token that can be displayed in the frontend.

The function is_activein jwtgen.py is located there because the refresh endpoint in #3270 needs to check if incoming tokens are active based on their claims. the is_active function in the JWTRefreshToken class will be used by the frontend to show if a token is active or not. By having the this function in jwtgen.py, the API and frontend can share the logic. Would be messy to have two different functions that could potentially disagree if a token is active.

[github-actions]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ PYTHON	black	3		0	0.59s
✅ PYTHON	ruff	3		0	0.01s

See detailed report in MegaLinter reports
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff

[github-actions]

Test results

   12 files     12 suites   11m 29s ⏱️
2 175 tests 2 175 ✅ 0 💤 0 ❌
6 000 runs  6 000 ✅ 0 💤 0 ❌

Results for commit e03278b.

♻️ This comment has been updated with latest results.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 60.76%. Comparing base (905a62f) to head (e03278b).
Report is 55 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3268      +/-   ##
==========================================
+ Coverage   60.58%   60.76%   +0.18%     
==========================================
  Files         606      606              
  Lines       43733    43782      +49     
  Branches       48       48              
==========================================
+ Hits        26494    26603     +109     
+ Misses      17227    17167      -60     
  Partials       12       12              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[hmpf]

The rest of NAV does not care about timezones. USE_TZ is False. Had it been True you could have used the "now" function in django.utils.timezone. Making NAV care about time zones is yet more techdebt we need to deal with eventually, but not now.

If timezones (including utc) is important for JWTs I recommend you write something about it in the body of an actual commit so that the info is not lost.

[stveit]

The rest of NAV does not care about timezones. USE_TZ is False. Had it been True you could have used the "now" function in django.utils.timezone. Making NAV care about time zones is yet more techdebt we need to deal with eventually, but not now.

If timezones (including utc) is important for JWTs I recommend you write something about it in the body of an actual commit so that the info is not lost.

JWT using unix timestamps for its claims isnt NAV specific, thats just how they work. But youre probably right that using timezones in the is_active function doesnt actually do anything. They should automatically be the same timezone if they're all naive, and the time delta between the timestamps and now is the only thing that matters in this context. I just did it this way since I believe its good practice to use UTC when you can, and in this case its isolated within the function so it shouldnt really cause any issues.

tl;dr I am fine with removing the timezones if we agree that it wont change the functionality

[johannaengland]

Some questions and some little test name changes

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud