Understand JWT: Access token vs Refresh token

Recently in one of my project I need to secure my REST API using JWT. Most of my previous projects were using serverless architecture and I always use AWS Cognito as a go-to solution.

When working with AWS Cognito, we need to deal with three tokens: ID token, access token and refresh token. Using Tokens with User Pools. AWS SDK and Amplify handle all the dirty-works related to token management, and provides couple APIs that enables easy and straight forward interface working with Cognito backend.

When I come to use Feathers as a building block for my new project, I bring the same expectation for Feathers. I was really surprised when I learned that Feathers only supports access token and no refresh token implementation.

Refresh-token actually is long-requested feature for Feathers since year 2015. Add support for refresh tokens #1337 After digging into the discussions in the issue, I found that there were some mis-understandings of refresh-token. Some people believe that re-issuing access-token is refresh-token. That’s not the case. Access token and refresh token are two totally different things.

The main purpose of refresh-token is to refresh the short-live access-token. Access-token can access user’s data and having a long-live access-token could cause security issue. That’s why access-token usually will expire in hour or even minutes. Once access-token expired, to avoid having user to login again, refresh-token is used to get a new access token. Refresh-token cannot access user’s data, so having a long live refresh token will have less security concern. In the worst case refresh-token also can be revoked.

Once refresh-token expired, user has to go through login process again to get a new refresh-token. There is not other way to refresh refresh-token.

Some key difference between access token and refresh token listed below:

Difference between access token and refresh token