django-rest-framework-jwt
django-rest-framework-jwt copied to clipboard
jpadilla
Why django-rest-framework-jwt uses "orig_iat" instead of "iat"?
RFC defines "Issued At" as "iat" not "orig_iat" => https://tools.ietf.org/html/rfc7519#section-4.1.6
I am curious as well. This seems very odd to me, even after digging around in the source. i see nothing about it or any context clues for the non standard name. still trying to find a clue... it was added in 5fc75bfe58ebb574d0ec60594eb506ba75bfac3c ... seems like there is no reason for the non standard name.
https://getblimp.github.io/django-rest-framework-jwt/#refresh-token
Refresh with tokens can be repeated (token1 -> token2 -> token3), but this chain of token stores the time that the original token (obtained with username/password credentials), as orig_iat. You can only keep refreshing tokens up to JWT_REFRESH_EXPIRATION_DELTA.
My understanding of this is that orig_iat is the original issued at timestamp, which is the one defining if you actually are allowed to keep refreshing your tokens.
This implementation is wrong. There should be two separate tokens. There should be a refresh token used exclusively with the identity provider to get new access tokens with a long expiration period (max session length). There should be an access token that is used exclusively with relying parties, that has a short expiration period. When an access token expires the refresh token is used to get a new access token.
JWTs are far from perfect. Sliding token implementations are less secure, to begin with. In addition, this is missing a blacklist, and using custom claims.
@dopry calling it a "poor/dangerous" implementation doesn't seem appropriate. if there are implementation issues with this package, which is used by many, why not open an issue and explain it to the community?
@erichonkanen, It's perfectly appropriate. The authors aren't following known RFCs for claims based authentication workflows. They are implementing custom claims and workflows without clearly documenting how and why their utilization is secure. The library doesn't seem to be actively maintained.
django-rest-framework-simplejwt is a better implementation which includes blacklists and generally follows the openid connect authorization flow.
Take that for what it's worth, use google and come to your own conclusions.
sorry about the late response. the original PR is here https://github.com/GetBlimp/django-rest-framework-jwt/pull/23, for some context
it is kind of a "custom" thing, and likely is not as secure as a separate refresh token approach. fwiw, it's an optional feature so the end user doesn't have to use this if they don't want to
i'm not really all that strongly attached to this approach/implementation, and would leave it to primary maintainer to make a decision on what to do or not do with this
@dopry I don't use and haven't been following this library lately at all, I'm just saying that it's fair to criticize but do it in a constructive manner.
I do remember that I had opened a PR for blacklists in this lib a long time ago and it was denied as the concept of "blacklist" seemed to go against the notion of stateless jwt (have to store the blacklist somewhere). There was also a PR for long-lived refresh tokens but not sure if it made it into the lib or not.
