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 ?
Hi, an MITM attack is not what the refresh token aims to prevent. The risk it has to mitigate is an access token leaking to an attacker (by any mean, eg XSS).
The idea being that you set a short expiration time for the access token, and refresh it with the refresh token when it has expired. The refresh token needs to be stored in a secure fashion.
The refresh token is most useful when the resource server is not the authentication server. Say if your resource server (RS) is also the client of the authentication server (AS) but acts as a middleman between your client (JS app in browser) and the AS (eg uses redirect with a retrieve from code flow). Then the RS can send the (unsecured) client an access token and store (eg in session) a refresh token, and process most requests without querying the AS.
If you’re both the RS and the AS, and need to store each client’s data on the server, why not use plain old sessions? If invalidating all clients sessions when one is compromised is acceptable, then you can use the iat and nbf claims to further validate the token.
In general, I would look long and and hard at whether you need jwt based authentication in the first place ( I mean, if you’re the AS, the RS and the one serving the client, use sessions, it’s easier and it has less footgun).
Thank you for sharing your insights, I have another question though.
I am using the jwt token in order to be stateles in the api side meaning in case I need to load balance the request I don’t need to share the sessions among the back end instances does this means I have to seperate my AS from the RS ? Meaning My understanding is that an authentication request comes in some instance is responsible for authenticating and then maybe another instance handles the resourse requesting but it’s going to be able to verify the token if they share the same secret(Is this somehow problematic for my architecture ?).
The XSS attack’s problem is I guess that it would have access to the stored tokens on the users browser machine since it would look like it’s executing from my client application. Did I got that part right ? But then I do not understand how the refresh token would be any different since they probably would also have access to the stored refresh token as well. I would just have a means in that case to invalidate them.
So I guess I could just store in my backend db the jwt (refresh their life span on request bases) and invalidate them on demand. But then the problem is that I hacked my way from JWT to plain old sessions right ? Does this have implications on my system apart from having an extra load on the database that would otherwise not be neccessery, or is it a reasonable way to move forward assuming I already have a token based authentication system in place ?
JWT (and similar “stateless” tokens) are reasonable in only one situation - when given token is short-lived and is one-time thing (for example download servers).
