我想在新的 REST API 中实现基于 jwt 的身份验证。但是过期是在令牌中设置的，是否可以自动延长它？ 我不希望用户需要每隔 x 分钟登录一次，如果他们在那段时间积极使用该应用程序的话。这将是一个巨大的用户体验失败。
但是延长到期时间会产生一个新的令牌(旧的令牌在到期之前仍然有效)。在每个请求之后生成一个新的令牌对我来说听起来很愚蠢。当多个令牌同时有效时，听起来像是一个安全问题。当然，我可以使用黑名单使旧的使用者无效，但是我需要存储令牌。
我发现了 Auth0可以解决这个问题，他们不仅使用 JWT 令牌，还使用了一个刷新令牌: https://docs.Auth0.com/refresh-token
但是，为了实现这一点(没有 Auth0) ，我需要存储刷新令牌并维护它们的过期。那么真正的好处是什么呢？ 为什么不只有一个令牌(不是 JWT) ，并在服务器上保持过期？
是否有其他选择? 使用 JWT 是否不适合此场景？
分享
I work at Auth0 and I was involved in the design of the refresh token feature.
It all depends on the type of application and here is our recommended approach.
A good pattern is to refresh the token before it expires.
Set the token expiration to one week and refresh the token every time the user open the web application and every one hour. If a user doesn't open the application for more than a week, they will have to login again and this is acceptable web application UX.
To refresh the token your API needs a new endpoint that receives a valid, not expired JWT and returns the same signed JWT with the new expiration field. Then the web application will store the token somewhere.
Most native applications do login once and only once.
The idea is that the refresh token never expires and it can be exchanged always for a valid JWT.
The problem with a token that never expires is that never means never. What do you do if you lose your phone? So, it needs to be identifiable by the user somehow and the application needs to provide a way to revoke access. We decided to use the device's name, e.g. "maryo's iPad". Then the user can go to the application and revoke access to "maryo's iPad".
Another approach is to revoke the refresh token on specific events. An interesting event is changing the password.
We believe that JWT is not useful for these use cases so we use a random generated string and we store it on our side.
分享
