0

I have a general question about the authentication flow with jwt tokens (access and refresh tokens).

How does the request - response flow looks like when the access token expires? I think of the following options.

Option 1

The frontend requests a resource with an expired access token so that the backend sends a 401 status code. The frontend has to call an specific endpoint for getting a new access token based on the refresh token. After the frontend has a new access token it has to call the first resource again.

With this option the frontend has to do 3 requests.

Option 2

The frontend requests a resource with an expired access token, but a valid refresh token in the cookies (httpOnly, sameSite, secure). The backend checks the access token and generates a new one (and maybe a new refresh token for token rotation) and pass the request to the requested resource.

With this option the frontend always has to do one request and gets the resource and new tokens when they expire.

My problem with option 1

The user triggers request 1. Then the backend send the status code 401. Now the frontend has to handle the response, execute the renew token request, handle that response too and has to know what request the user initial wanted to execute and needs to do this request again.

Seems to be to complicated for such an "easy" thing (Hint: this is the way i implemented it right now).

My problem with option 2

Option 2 seems to be a good idea. Only one request will be executed and the frontend doesn't need to handle the whole renew and execute the first request again thing. Right now i don't see any security issues. But when i always send the refresh token within a cookie to get a new access token, why i shouldn't create a long life access token and store this in a cookie. No javascript can access this type of cookie. And when this token will be stolen anyway, i can implement a quicker token rotation. (I have to say that i store the refresh token in a database. So only this specific refresh token is valid to the backend independent of the validity of earlier created refresh tokens)

So i don't know how to handle this authentication process the best way.

Here is one tutorial for the first option i think. The whole frontend part for renewing the token and execute the first request again part is not explaind.

Authentication Flow Option 1

Here is a simliar question. But the answere doesn't describe my problem too. How does the frontend executes request E after steps F to H are done: Authentication Flow Stack Overflow

Thomas Mueller
  • 71
  • 1
  • 6

1 Answers1

0

If you have seperate back-end and front-end's, i think it's the best way to handle jwt authentication is setting the maxAge of jwt very high and when your front-end refresh the page and send request give token again, and set your cookie's maxAge lower. The idea under the refresh token is sending tokens again and again and setting auth cookies with the same name and value again all the time, so keep your users always online if they're keep using your website.

If your application is an admin panel so no one will try to manipulate or steal your sensitive infos that's easiest solution. But if your application is open for other users and you give them to jwt tokens all the time, then using a seperate front-end or a csr framework is not a good approach, if you want to use seperate front-end or a csr framework, for example react you should handle your authentication with redux instead, for sake of security purposes but it's more dirtier than jwt authentication and no one likes that, everyone hates dealing with react's original authentication solutions. You can find another auth solutions for vue or angular or any other front-end framework.

In conclusion, using a csr framework for front-end is bad idea most of the time. You should use a meta(ssr) framework if you want to make authentication easier or simply go with monolith apps, it's the most easiest way to make apps.

Necoo33
  • 11
  • 3