Token expiration and refresh tokens

When we implemented JWT token authentication in Chapter 8, Third-Party Authentication and External Providers, we didn't bother much about the token expiration time. We just set its value to an insanely high amount (86,400 minutes, which corresponds to 2 months) and went ahead with the coding. That was great for demonstration purposes, yet it won't be ideal when publishing our project into production. Issuing tokens with such a broad lifespan outside of a test environment will definitely pose a serious security threat. However, we don't want our users to be kicked out and/or lose their auth privileges because the token expires before they're done with their login session; is there a way to drastically reduce the token lifespan while also avoiding the risk of kicking active users out?

The answer is yes; to do so, we have to implement refresh tokens in our existing authentication pattern and learn how to properly use them to let our clients renew their tokens in a transparent way. However, before we start working on them, let's spend some valuable time to understand why we need to do that.

A small terminology clarification before we start; from now on, we will refer to the JWT tokens we implemented in Chapter 8, Authentication and Authorization, as access tokens, to distinguish them from the refresh tokens that we'll implement now.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.145.70.170