Hello Fellas,

I need to wrap my head around a topic that I do not seem to see through.

I am developing a phoenix application which exposes a RestApi that is the primary mean of communication with the Client (an elm application), the phoenix app runs over https and all request are https request.

Right now my process for securing my API is simple, a user uppon login gets a jwt token with an hour expiration time, every time he is making a request a new token with an hour expiration time is issued, once he has not login for more than an hour the user is getting a 401 response from the next request to the server and is forced to re Log-in to to the application and so on.

But I have been looking about refresh tokens that you can provide to the user along with the access token and how you can store them in your database(Server side) and thus invalidate them once you see a user in risk. The primary benefit of that is explained to be that in the case of a Man in the middle attack the “man in the middle” can potentially aquire the users token and use the token to make request on his behalf.

My question at this point is simple. Does this risk really exist in the case of all communication happening through https ? Does it really make sense to have that kind of functionallity in the server when you do not have a fraud detections system meaning that if a user himself reports a hacked account your are not sure if the token is somehow systematically being aquired or if the credentials have been compromised and you would probably want to suspend the account completly ?

Thanks in advance !