IndominusByte / fastapi-jwt-auth

FastAPI extension that provides JWT Auth support (secure, easy to use, and lightweight)
http://indominusbyte.github.io/fastapi-jwt-auth/
MIT License
644 stars 150 forks source link

How to use different secrety_key per user (eg to invalidate devices on password-change) #26

Open lefnire opened 3 years ago

lefnire commented 3 years ago

Looks like AuthJWT loads config one time, then sets that secret_key to be used for later fetch via self._get_secret_key()

class Settings(BaseModel):
    authjwt_secret_key: str = SECRET

@AuthJWT.load_config
def get_config():
    return Settings()

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 using secret_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 for access_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?)

IndominusByte commented 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

lefnire commented 3 years ago

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.

IndominusByte commented 3 years ago

maybe in the next version, I'll be considering your idea and do some research about it, thank you 😄🙏

lefnire commented 3 years ago

Thank you!

florianabel commented 1 year ago

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?

demoh2019 commented 1 year ago

+1