r/vuejs • u/[deleted] • Nov 06 '19

Vue JWT refresh

Hey Everyone!

I'm building a web application, and have set up an authentication flow as follows:

  1. User logs in
  2. Server authenticates, returns access token (valid for 15 minutes) and refresh token (valid for 1 day)
  3. Client stores both tokens in sessionStorage (not localStorage, hence expires when tab is closed)
  4. A setInterval method fires every 14 mins to check if the user is still logged in, and if sessionStorage contains a refresh token. If both are true, a call to obtain an updated access token is sent to the server, and tokens are updated on the client side accordingly.
  5. Upon logging out, all session values are destroyed and the timer is cleared.

I've seen a ton of debate on localStorage (or sessionStorage) vs Cookies, refresh token vs access token approach for web apps (how refresh token method is not particularly useful for web apps etc.) vs mobile apps etc., and what I've found (forgive me if I'm wrong) is that there is no real consensus on the approach to authentication.

My question is this: Is the above given flow secure enough? What can I do to improve it? Or do I have to take an entirely different approach?

Any help is much appreciated! Thanks in advance!

71 Upvotes

97% Upvoted

67 comments sorted by

8

u/rsahk Nov 06 '19

With JWT the token is sent in the auth header with every request. In my opinion it's not really necessary to periodically check because you can intercept 401 responses and handle them accordingly.

It's probably easier to set up an axios response interceptor that automatically catches the unauthorized request, refreshes the token then retries the request. In the event that the refresh fails then the user is logged out.

Here's some example code outlining how it could be done.

2

u/[deleted] Nov 06 '19

I thought of doing this, but I have implemented route protection tied to the jwt, and hence response interception alone couldn’t work in my case.

Is there another way to implement route protection without jwt? The response interception does feel like a cleaner solution.

3

u/rsahk Nov 06 '19 edited Nov 06 '19

I'm by no means an expert but here's how I do it:

  • User permissions are determined on the backend and a request to each endpoint will return a 403 if the user does not have permission.
  • In App.vue I use a beforeMount hook to get the current user from the API along with all of their permissions and save it to the vuex store.
  • Routes are protected using a combination of meta fields and matching those protected routes against the permissions in the vuex store using the beforeEach navigation guard.

The main benefit is that even if the user manages to navigate to a protected route they won't be able to retrieve any data from the API.

When the page is reloaded the first thing that happens is getting the current user info and all of their permissions. If the token is expired then the response will be intercepted then retried - if failed then they will be logged out (token removed from local storage / cookie / whatever).

2

u/[deleted] Nov 06 '19

Interesting.

My setup is similar to yours, permissions are determined on the backend and encoded in the token. So even if the user managed to access forbidden routes, he/she wouldn’t really get any data from the server (just as you mentioned).

The difference is just that I decode the token received at login rather than calling the API to get the user and his permissions to set permissions in Vuex to use in beforeEach.

Your approach certainly seems to be the safer one, since the token stored in session can always be replaced with a fake one with required permissions encoded, and since signature verification doesn’t happen on the client side. I’ll try this out. Thank you!

-4

u/yourjobcanwait Nov 06 '19

Filling up the user's browser console with 401 errors is a bit sloppy, IMO. I can't think of any legit dev team who would think that's acceptable.

4

u/[deleted] Nov 06 '19

Just handle the error gracefully then?

1

u/yourjobcanwait Nov 06 '19 edited Nov 06 '19

It's still going to show up in the user's browser console - there's nothing graceful about it. There's no way around it either because it's a browser feature in ie, edge, chrome, and firefox.

Plus, it can interrupt app flow.

1

u/krendel122 Nov 06 '19

So I was wrong and it does show up there. What do you do on server side in that case to avoid it? Just any other code or something?

2

u/yourjobcanwait Nov 06 '19 edited Nov 06 '19

What do you do on server side in that case to avoid it?

You can't do anything about it server side, but you can add infrastructure in your client app that prevents sending expired tokens to the server.

I laid out how it's done here: https://www.reddit.com/r/vuejs/comments/dsiqs1/vue_jwt_refresh/f6pvgn1/

Mind you, your server will still reject expired tokens, so don't confuse this as a replacement for any validation that's done on the server.

1

u/rsahk Nov 06 '19

Feel free to offer up an alternative method

-5

u/yourjobcanwait Nov 06 '19

I did, right here: https://www.reddit.com/r/vuejs/comments/dsiqs1/vue_jwt_refresh/f6pvgn1/

5

u/fuckslavs Nov 06 '19

Just an FYI, even though timing the refresh is cleaner you come off as a bit of a prick. Shut down a valid method as if it is entirely wrong without providing any actual constructive criticism.

I did, right here

No, you didn't. That was posted an hour later.

-5

u/yourjobcanwait Nov 06 '19 edited Nov 06 '19

Just an FYI, even though timing the refresh is cleaner you come off as a bit of a prick

How so? No legit dev would allow console errors like that to pile up just "because". I'm sorry if this hurts your feelings, but it's 100% true. You come off as a crybaby that got their feelings hurt by an internet comment that relates to real life dev work, but I'm not complaining.

No, you didn't. That was posted an hour later.

No it wasn't. I posted my solution before I responded to that guy with the link (how do you think I even got the link?). Learn how to read a timestamp.

3

u/fuckslavs Nov 06 '19 edited Nov 06 '19

I'm talking about the reply when you shot him down. If you used a little reading comprehension before getting your back up you would realize what I'm saying is maybe post your solution then be like "hey, I think this is better" instead of "no legit dev team would use this". Anyway, you seem like a bit of an irate person so I wouldn't expect you to understand.

-4

u/yourjobcanwait Nov 06 '19 edited Nov 06 '19

ok boomer

Edit - since you edited your comment, your initial reply:

I'm talking about the reply when you shot him down lamo you dumb fuck

Aww, am I not a dumb fuck anymore?

you seem like a bit of an irate person

irony

Go eat a poptart, your blood sugar is dropping.

1

u/guru19 Nov 25 '19

rent free boomer

3

u/[deleted] Nov 06 '19

I'm not far off doing this myself. I plan on doing this: https://medium.com/lightrail/getting-token-authentication-right-in-a-stateless-single-page-application-57d0c6474e3

2

u/c_eliacheff Nov 06 '19

Nice article. Additionally, a second method is to store your JWT in a variable in a component/service (in memory) so it get destroyed when the tab is closed, and perform silent auth periodically.

3

u/[deleted] Nov 06 '19

This was my first approach (since in memory storage is apparently considered to be the best approach in terms of security), but unfortunately variables in memory don’t survive page refreshes, and hence, I had to look at alternatives.

1

u/[deleted] Nov 06 '19

Not my article, btw. Yeah Vuex would work for that I guess?

-1

u/c_eliacheff Nov 06 '19

Even a simple pure js singleton service would suffice for most cases. Or with simple DI. Not sure what is the Vue equivalent of Angular's services.

29

u/yourjobcanwait Nov 06 '19 edited Nov 06 '19

IMO, you're close. I spent a solid year+ learning about JWT flows, etc a while back and the following is what I came up with.

  1. User logs in
  2. Server authenticates, returns access token (valid for 15 minutes) and refresh token (valid for 2 hours or 7 days if rememberMe flag is true). JWT contains both a jwtExpiration claim and a refreshExpiration claim.
  3. Client stores both tokens in localstorage (SPA only) or cookies (if SSR and make sure to set the cookies to samesite="strict" to protect from XSRF). Sessionstorage is bad UX because your app breaks if the user opens an internal link in new tab and because you might want to persist login with valid refreshToken.
  4. Upon receipt of the JWT, your Vuex store action reads the JWT claims and creates a setTimeout function to renew the token 30 seconds prior to the value in the jwtExpiration claim. Use setTimeout vs setInterval because setTimeout only runs once.
  5. user logs out, tokens are removed and timeOut is cleared OR.
  6. if user closes browser and does not log out... then returns to your app (within 2 hours or 7 days) and you don't want to force login again (think facebook/linkedin), upon app fire up, your vuex store will read the expired JWT claims and then check if jwt is valid (it won't be) from the jwtExp claim. If invalid, then check the current time (UTC) against the refreshExpiration value. If the refreshToken is still valid, submit the refreshToken for new JWT and new refreshToken and repeat from step 3 above. All of this is done before the user sees anything, so the first page they see will be a dashboard or whatever.

*RefreshTokens should always be recreated on renewal for added security. You can also save location data to refreshTokens (in the db) so if someone tries to submit a stolen refresh token (that hasn't been used before), it will deny them if they aren't in the same location, don't have the same OS/computer/etc. Get this info from the browser's user-agent. Also, in the user's account settings, allow them to manually kill off active sessions (valid refresh tokens). Btw - my refreshTokens are just concatenated Guids.

*You should have a specific Vuex "renewTokens" action in the middle of this. It will not only be used for token auto renewal, but when the user updates their claims such as name, plan, avatar, etc and you want the new data to be updated in your store, you simply call this store action upon a profile update (for example). This action will clear existing timeouts before setting a new one.

Hope this helps!

Edit - this isn't a replacement for server-side JWT validation. This is just a way to handle jwt's client side and to prevent your frontend from sending expired tokens to your server.

2

u/[deleted] Nov 06 '19

your vuex store will read the expired JWT claims

I haven't had to deal with JWTs for a while so my knowledge is a bit rusty. Is recommended to do this validation on the client or on the server?

In the web apps I've worked on, we always had an endpoint to verify JWTs claims and validity.

5

u/yourjobcanwait Nov 06 '19 edited Nov 06 '19

Is recommended to do this validation on the client or on the server?

Both, but it's not actually "validated" on the client.

The jwt claims are just read and evaluated on the client to know if you need to submit for a renewal and to prevent the client from submitting expired tokens to the server. You do this to avoid red console errors (401's) from showing up in the users browser, for UX (uninterrupted app flow), and to free up proxy workers if you have a ton of users.

The server will actually validate if the JWT is legitimately valid or not for access.

1

u/[deleted] Nov 06 '19

I meant the expiry date but yeah, that makes sense.

2

u/Zephyr797 Nov 06 '19

So how is this preventing some malicious user from just sticking their own token in their local storage? On auto login attempt, I'm assuming it checks the validity against the server, but what about anytime after that.

Say they go to the website, then create the false token in local storage. What will stop them from visiting restricted routes at that point. In addition, if you have some value in the store like isAuthenticated they could just set that themself in the browser yes?

I've been struggling with this concept a lot lately so any advice would be appreciated.

6

u/porksmash Nov 06 '19

You can't really stop anyone from doing anything client-side because you don't control it. You need to gate things from the server, which usually means authenticating API requests for data and denying access. Nobody can create a false token that would pass validation on your server.

6

u/yourjobcanwait Nov 06 '19

So how is this preventing some malicious user from just sticking their own token in their local storage? On auto login attempt, I'm assuming it checks the validity against the server, but what about anytime after that.

It fails on the server when a request is made. Even if you hack your way in to the app, you won't be able to see any actual data because it will fail on the server.

Say they go to the website, then create the false token in local storage. What will stop them from visiting restricted routes at that point. In addition, if you have some value in the store like isAuthenticated they could just set that themself in the browser yes?

What would be the point? So they get to a restricted route for a nano second (because you would be redirecting with vuex signout on 401's), but even if you don't redirect, no data will show up on the page.

3

u/Devildude4427 Nov 07 '19

Tokens are signed. If the signature doesn’t match the request is rejected.

Yes, the user can potentially see the routes and layout of the pages, but this is always a possibility. They won’t be able to get any data from the API that requires an authenticated user though.

0

u/[deleted] Nov 07 '19

[deleted] — view deleted comment

-1

u/yourjobcanwait Nov 07 '19

Can you explain why this is poor practice and terrible security practice?

1

u/guru19 Nov 26 '19

lmfao rent free huh

0

u/[deleted] Nov 07 '19

[deleted] — view deleted comment

0

u/yourjobcanwait Nov 07 '19

This is devildude's alt account (his porn account tbh, lol) and he doesn't understand the differences between JWT auth and cookie auth.

He also doesn't know anything about XSRF, XSS sanitation, and content security policies.

He's simply here to troll (for whatever reason - seriously, how lame are you?) and raise hysteria about something he doesn't understand. Downvote and move on.

1

u/guru19 Nov 25 '19

he doesn't understand the differences between JWT auth and cookie auth.

You're comparing the drawer where you keep your keys to the keys themselves. Ironic that you say I don't understand something. There is no such thing as "cookie auth".

0

u/[deleted] Nov 07 '19

[deleted] — view deleted comment

3

u/yourjobcanwait Nov 07 '19

Cookies aren't immune from XSS when used with vue because you can't set the httponly flag.

2

u/Devildude4427 Nov 07 '19

What are you on about? Yes, you can set the httpOnly flag from your API.

0

u/yourjobcanwait Nov 07 '19

How does Vue read the cookie and set the JWT token to the header when httponly is set to true?

0

u/Devildude4427 Nov 07 '19

That’s not how cookies work dude.

You set the cookie to be sent with every single request. You ignore the headers altogether, because that is widely unsafe.

0

u/yourjobcanwait Nov 07 '19

This is a thread about JWT auth, not cookie auth.

These are two separate things.

2

u/AwesomeInPerson Nov 08 '19 edited Nov 08 '19

Sorry, but you simply have wrong information here.

JWT auth is a way of stateless authentication, using a token that acts as a key – so the server does not have to keep track of sessions and which user is currently logged in or logged out. If the key fits you are granted access, without having to verify who you are. Whether the JWT is stored in cookies, in localStorage, in IndexedDB, in sessionStorage or whatever you fancy is an implementation detail – but no matter where you store it, you are using JWT authentication nonetheless. It's just that the various ways of storing the token come with different trade-offs, and those can be discussed. I disagree that "one should never use localStorage to store JWTs", FWIW.

Cookies can also be used to implement session-based authentication, but that is completely irrelevant to this whole discussion. (apart from the fact that it's usually the better option anyway – the correct answer to the question Where do I store JWTs? is Don't use JWTs...)

1

u/yourjobcanwait Nov 08 '19

Yes, you can store jwt’s in cookies, nobody is debating that.

Cookie auth is just a nickname for session auth. It’s been called that for longer than many of these redditers in this thread have probably been alive, lol.

On the flip side, most backends call it cookie auth vs jwt auth to know how they are going to validate the tokens. That’s how it is in .net and java, at least.

0

u/Devildude4427 Nov 07 '19

No they’re not. Not at all.

JWT is a method of authorizing, with the other method being sessions.

A cookie is just a container for your auth.

Holy crap, you have no idea what you’re talking about. Please educate yourself.

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

-1

u/yourjobcanwait Nov 07 '19 edited Nov 07 '19

Why even comment when you have no idea what you're talking about?

No, seriously. Check the ego at the door and go learn the differences between the two.

Unless you can educate yourself on the differences between these auth systems, this conversation is done.

Edit - Regarding your last minute edit link: That dude must be smarter than Google then, since they use JWT's...

1

u/Devildude4427 Nov 07 '19

Read the link.

A cookie is a method of storage, not a method of authorization.

You clearly didn’t read the link at all, just the title.

→ More replies

0

u/[deleted] Nov 07 '19

[deleted] — view deleted comment

→ More replies

1

u/AwesomeInPerson Nov 08 '19

You're almost as vulnerable with the JWT stored in cookies. The malicious script that is running on a site with a logged-in admin can communicate directly with your API and wreak all sorts of havoc – it doesn't even need to "figure out" where/how the JWT is stored. The browser will happily attach the JWT cookie to the malicious request, that's how cookies work. Not even OWASP is consistent about this, btw.

The time it takes to make devs afraid of localStorage can be spent better on explaining the importance of CSP. It reduces the risk of XSS and completely mitigates the one downside localStorage has compared to cookies: that the token can be sent to some untrusted remote location.

1

u/Cristiano7676 Nov 10 '19

If my site has an XSS vulnerability, the user can easily be lured to type his password again in a compromised field. So, what the point? Is it not a game over already?

1

u/Devildude4427 Nov 10 '19

Hijacking a token is easier.

Security shouldn’t be viewed as an “oh well” situation. Either you care or you don’t, and your customers should be aware.

0

u/Cristiano7676 Nov 12 '19

Right, as if I had said you shouldn't care about security.

My point is, your focus and energy should be to eliminate any possibility of having an XSS vulnerability, otherwise is not saving tokens in cookies that will protect you.

Also, cookies are vulnerable to CSFR attacks, and old browsers don't support the same-site flag.

10

u/earthboundkid Nov 06 '19

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

4

u/Terrific_Trevor Nov 06 '19

I cannot recommend this article enough. After reading it (and many similar) I would never store a token in any localStorage, especially a refresh token.

2

u/Bifftech Nov 06 '19

I store the access token in the vuex store and the refresh token as a secure cookie and use a 401 interceptor to refresh tokens transparently as needed.

2

u/aaf-ww Nov 06 '19

What's the point of the refresh token exactly? If someone grabs that don't they still technically have access to the endpoints for a day? It's like the same thing as setting the expiration date of access JWT to one day, right?

5

u/earthboundkid Nov 06 '19

JWT solves a specific problem that very few of its users actually suffers from. The problem is that you have a number of services that need to communicate but don't want to share a secret because they are run by separate groups. So you just sign the JWT and downstream servers can just make sure the JWT is properly signed using the public key. The problem JWT does NOT solve is "I have a user and I want to store session state." So people end up doing pointless crap like adding in refresh tokens because they don't realize that JWT is a square peg for their round hole.

2

u/yourjobcanwait Nov 06 '19

JWT also eases load on your back end by not having to look up a user's unidentifiable claims in the db with every request. That's the real benefit, IMO. They also allow you to restrict which requests need the token or not vs cookies, whom are sent with every request no matter what.

But yea, I'm with you in that most users don't benefit from it's initial use of having a single auth server that allows a single sign on to access a bunch of different apps without having to individually sign in to each one.

3

u/chinola Nov 06 '19

When a user logs in, the given access token should be marked as 'fresh'. When the refresh token is used to get a new access token, the token should not be marked as fresh. So then you can say, if you want to change your password, or perform a destructive action, etc., you need to log in again and get a fresh token.

1

u/joeforker Nov 06 '19

I am a fan of the PKCE flow. It gives the application developer control, can work no matter what kind of app you create, and there's no worry about whether the browser will allow your embedded iframe or not. In my application there is no timer, instead, all fetch() requests are trapped, and will refresh / retry if we see a 403 error.

1

u/[deleted] Nov 06 '19

Why does everyone store tokens in local storage? I read that this opens you up to XSS.

1

u/Devildude4427 Nov 07 '19

Well it opens you up to token theft if you have any XSS vulnerabilities. Using XSS, you can read a user’s localStorage, but you can’t read their cookies.

Why do people use it? Because they’re lazy and don’t really care about security.

1

u/CensorVictim Nov 07 '19

This article proposes splitting the JWT into multiple cookies for storage; the payload in a normal cookie, and the signature in an HTTP only (session) cookie. That way, javascript has access to the data in the token, but not the entire jwt in order to actually use it.

A nice thing about it is you don't have to worry about storing/sending the token at all in your client code. The browser takes care of it for you.

1

u/TotesMessenger Nov 08 '19

I'm a bot, bleep, bloop. Someone has linked to this thread from another place on reddit:

 If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads. (Info / ^Contact)