What the hell is Refresh token?
Recently, I received a nice question from a junior guy, he is working on a project that required API authentication (JWT Oauth).
He asked me: “Hey Phuc, I don’t get it, what is the purpose of Refresh Token? Why don’t we just use the Access token with the longer expiration time instead – 99 years for example? What the hell is Refresh token?”
I think that is a good question, I also asked myself that question a few years ago when I tried to implement an OAuth flow for the first time. So now after finishing many projects using JWT authentication, I want to share some examples to explain the difference between Refresh token and Access token, and why we still need both as well.
1. Simple first
Access token is an encrypted string you give to your user, they will attach that token to every request that requires authentication in your application. Your server will receive that token and decode it to see if it’s valid or not. An access token should have an expired time, I usually set it 24 hours in my applications. After they log in 24 hours, that token will be expired and users have to log in again – unless they refresh that token .
On another hand, refresh token is an encrypted string that we can use to refresh the access token. A refresh token should never die (never expired).
Okay, after read my definitions about access token and refresh token. A new question comes up to your mind: “So why don’t we just set the access token to never die instead of 24 hours as you said? And then I don’t need to give a shit about Refresh token”
You’re right, now we gonna discuss the difference between Refresh token and Access token with a very long live.
2. The different:
First of all, let’s take a look at this flow:
Figure 2.1: How JWT Auth works.
As you can see, when our users login in, we send back to them an access token – which they can save to their local browser. We don’t send to our user Refresh token, and in our client application, even if we send a refresh token back to the user, we don’t save it to the browser (well, I hope you didn’t do that :)).
Why? Because Refresh token is only used to communicate between our server and another authorized server. We only save refresh token on database of the server – which is much more secure. Let me repeat this one more time: DO NOT save refresh token to client’s device.
So, long story short, the difference between access token and refresh token is:
- Access token is used to communicate between client’s device and our server, so we can save it to client’s device – such as local storage or cookie.
- Refresh token is used to communicate between Server to Server. And therefore cannot be saved to client’s device, we save it on our Database.
3. Real world example
Until now, you already know that Refresh token is only used to communicate between server and server. You may wonder: “Okay, but what the hell is that mean? Server to server?”. So I think it’s better to give you an example which I face every day in my job.
Let’s assume that we have an application to read Advertisements from Facebook via Facebook’s API:
Figure 3.1: The flow of my app
- In the first step, we redirect user to Facebook and ask for “Ads read” permission for their FB account
- They will log in and then grant permission to us. After that, Facebook will redirect user back to our application with Refresh Token (in header or url)
- We received that refresh token and save it to our Database on server.
- Later on, when we need to read Ads information, we just need to use that refresh token to refresh a new access token to get data via Facebook API.
So as you can see, refresh token is only used to communicate between our Server and Facebook server. Both servers are authorized and secure. We don’t use refresh tokens for client-side, right?
Now, I hope that you already understand the real purpose of Refresh token, it’s simple when we have a real example 🙂