如何实现刷新令牌功能前端

Security in front-end applications differ based on requirements and as an engineer, your task is to meet those requirements while keeping a remarkable experience for your users. Using the Bearer Token authentication mechanism you would notice some differences in the approach when designing some applications. Financial apps require constant authentication and re-authentication to protect access to your money, but for less serious apps like educational apps and apps for media consumption it's going to be a bad experience for your users to be reauthenticating themselves anytime they come back to your app. Before you proceed with this article there are certain things you should be aware of:

前端应用程序中的安全性根据要求而有所不同，作为工程师，您的任务是要满足这些要求，同时为用户保留出色的体验。 使用Bearer Token身份验证机制，您会在设计某些应用程序时注意到方法上的一些差异。 金融应用程序需要不断进行身份验证和重新身份验证，以保护对您的资金的访问权限，但是对于不那么严肃的应用程序(例如教育应用程序和用于媒体消费的应用程序)，用户每次返回到您的应用程序时都要重新进行身份验证将是一种糟糕的体验。 在继续本文之前，您应该注意以下几点：

1. This article only covers the Bearer Token method of authentication in building applications.
   本文仅介绍构建应用程序中身份验证的Bearer Token方法。
2. This article assumes you have adequate knowledge of authentication using the Bearer Token method.
   本文假定您具有使用Bearer Token方法进行身份验证的足够知识。
3. This article assumes you have proper knowledge of Axios (Promise based HTTP client for the browser and node.js).
   本文假定您具有Axios(用于浏览器和node.js的基于Promise的HTTP客户端)的适当知识。
4. This article assumes you are using Axios for your HTTP client as using other clients may differ.
   本文假定您将Axios用于HTTP客户端，因为使用其他客户端可能有所不同。
5. This article does not cover the back-end aspect of a refresh-token functionality. It assumes the API’s are ready for the refresh-token and is supposed to guide you on how to go about implementing the front-end aspect.
   本文不介绍刷新令牌功能的后端方面。 它假定API已准备好进行刷新令牌，并且将指导您如何实现前端方面。

THE PROBLEM

问题

The defacto way for building applications is to authenticate your users then when the backend invalidates their token you throw them back at a log-in page which works but it may break the flow of usage for the application. Imagine you scrolling through your Instagram and you were to leave it for say a day and the moment you revisit it, it slams you back at a log-in page. It is not rocket science to discover when such an experience becomes a bottleneck and a suitable solution to this is to implement a refresh-token functionality for your application whereas when the token has expired quickly request for a new one. In order to fully implement this solution we need to come up with answers to the following questions:

构建应用程序的实际方法是对用户进行身份验证，然后在后端使他们的令牌无效时，您将他们扔回到登录页面，该页面可以运行，但可能会中断应用程序的使用流程。 想象一下，您在Instagram上滚动浏览时，要留出一天的时间，并在重新访问它的那一刻，它让您回到登录页面。 发现这种经历何时成为瓶颈，而对此的合适解决方案是为您的应用程序实现刷新令牌功能，而当令牌过期后，快速请求新的令牌解决方案并不是火箭科学。 为了完全实施此解决方案，我们需要提出以下问题的答案：

1. How would a refresh token work?
   刷新令牌将如何工作？
2. What data do we need to implement a refresh-token solution?
   我们需要什么数据来实现刷新令牌解决方案？
3. Where/how would we store/read our refresh-token related data?
   我们将在哪里/如何存储/读取与刷新令牌相关的数据？
4. How do we effective