Add JWT refresh token model #2569
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2569 +/- ##
==========================================
+ Coverage 55.19% 55.51% +0.31%
==========================================
Files 561 567 +6
Lines 40917 41221 +304
==========================================
+ Hits 22584 22883 +299
- Misses 18333 18338 +5 ☔ View full report in Codecov by Sentry. |
stveit
force-pushed
the
jwt-refresh-model
branch
from
0280cc8 to
10b0c13
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
stveit
force-pushed
the
jwt-refresh-model
branch
from
10b0c13 to
b7a8fa6
Compare
Now shows very clearly that you are getting exp calim or nbf claim
no longer needed for testing, found better way
doesnt actually do anything. if you set it to the past, then its valid and if you set it to the future then it will eventually be valid. setting exp to the past is enought to deactivate it for good
doesnt really add anything
"data" and "body" were both used for the same thing, so changed to only use one of the terms for clarity
tricky tests to name ..
|
Kudos, SonarCloud Quality Gate passed!
|
stveit
force-pushed
the
jwt-refresh-model
branch
from
08c1893 to
5921a3e
Compare
|
|
Closing this on the premise that storing JWTs really does go against the point of it, and if we want to store refresh tokens in the database then we should probably have a different approach alltogether |
Adds model representing JWT refresh token, with class functions for generating both refresh and access tokens.
The model is basically a wrapper around a JWT, with some functions to interact with it. The intended use is for the API view accepting refresh tokens to use
JWTRefreshToken.objects.get(token=sometoken)to see if the refresh token is real, and useis_active()to see if its still active. If the token active, then an access token is generated and returned to the user, alongside a new refresh token overriding the current one.expire()exists in case a refresh token is leaked, or any other reason why you would want to effectively disable a refresh token.A JWT being stored in the database does go against the idea of having all necessary info inside the token,
but this is more or less necessary since it allows deactivating a refresh token. If an attacker got a hold of an active refresh token
with no way for the NAV admins to disable the token, then the attacker can generate access tokens forever.
The alternative is using a blacklist, maybe some way to detect if a refresh token is used twice or something along those lines.
I figured a whitelist approach is more reasonable. Access tokens will still exist entirely by themselves, with no reference in the DB. This works fine since they have a limited lifespan, so its not the end of the world if an attacker gets a hold of one.