Open lefnire opened 3 years ago
well if you adding a password as a claim is that insecure because the user or attacker can see the raw token in jwt.io, if you consider about double hashed you can use the Asymmetric Algorithm which uses a public-private key to hash the token, and for a custom secret key you can add when you create the token because in protected endpoint function is that dynamic decode token
Thanks for the response, I'll scrap the claims idea then & think about Asymmetric.
for a custom secret key you can add when you create the token because in protected endpoint function is that dynamic decode token
I'll chew on this a bit. I think custom key is the right way, so I'll see if there's a solution here.
maybe in the next version, I'll be considering your idea and do some research about it, thank you 😄🙏
Thank you!
Hey everybody, since I am currently faced with implementing a refresh pattern and how to do it best (Using fastapi-user, maybe fastapi-jwt-auth, other options) I was wondering if this is still being considered or how the status in general is?
+1
Looks like AuthJWT loads config one time, then sets that secret_key to be used for later fetch via
self._get_secret_key()
A pattern I've seen in tutorials to invalidate other devices after a user changes their password (if they got hacked, or just want to be on the safe side) is this.
refresh_token
is encoded and decoded usingsecret_key=f"{SERVER_SECRET}-{user.hashed_password}"
. Then since the latter is different post password-change, the hacked refresh_token will throw a decode error. I think the same can be done foraccess_token
, but maybe less critical since they can expire quickly?Anyway, would it be worth consideration to add a custom secret_key per
Authorize.jwt_required()
call, maybe an argument to that function? Or is there another way about this you can think of, eg adding the hashed password as a claim (is that insecure? I'm thinking it gets double-hashed here?)