nikolis

Authentication Strategy for token based authentication and Refresh tokens

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 !

3 comments

/phoenix #security #architecture #jwt #guardian

0 2647 3

2020-08-28 12:33:29 UTC

Most Liked

krstfk

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).

Post #1

Last Post!

hauleth

Stateless JWT is like honest politician, everyone speaks about them, but these are rare beasts, yet to be seen in the outer world.

Just use stateful tokens, for example session cookies. Nothing prevents the API to use them. Advantages of stateful tokens:

better usage tracking - you can always inform user when was the last time given token was used
you can easily revoke existing tokens in case of breach

If you have found “way around it”, then check this flowchart.

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).

Post #3