基于此实现的Node.js的JWT与刷新令牌:

In this case they use a uid and it's not a JWT. When they refresh the token they send the refresh token and the user. If you implement it as a JWT, you don't need to send the user, because it would be inside the JWT. They implement this in a separate document (table). It makes sense to me because a user can be logged in in different client applications and it could have a refresh token by app. If the user lose a device with one app installed, the refresh token of that device could be invalidated without affecting the other logged in devices. In this implementation, it response to the log in method with both, access token and refresh token. It seems correct to me.

以下是撤销JWT访问令牌的步骤:

When you do log in, send 2 tokens (Access token, Refresh token) in response to the client. The access token will have less expiry time and Refresh will have long expiry time. The client (Front end) will store refresh token in an httponly cookie and access token in local storage. The client will use an access token for calling APIs. But when it expires, you call auth server API to get the new token (refresh token is automatically added to http request since it's stored in cookies). Your auth server will have an API exposed which will accept refresh token and checks for its validity and return a new access token. Once the refresh token is expired, the User will be logged out.

如果你需要更多细节，请告诉我，我也可以分享代码(Java + Spring引导)。

关于你的问题:

Q1:这是另一款索赔较少、有效期较长的JWT。

问题2:它不会在数据库中。后端不会存储在任何地方。他们只会用私钥/公钥解密令牌，并用到期时间验证它。

Q3:是的，正确

OAuth 2.0规范文档中描述了刷新令牌流。

  +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+
  
  
  (A)  The client requests an access token by authenticating with the
       authorization server and presenting an authorization grant.
  
  (B)  The authorization server authenticates the client and validates
       the authorization grant, and if valid, issues an access token
       and a refresh token.
  
  (C)  The client makes a protected resource request to the resource
       server by presenting the access token.
  
  (D)  The resource server validates the access token, and if valid,
       serves the request.
  
  (E)  Steps (C) and (D) repeat until the access token expires.  If the
       client knows the access token expired, it skips to step (G);
       otherwise, it makes another protected resource request.
  
  (F)  Since the access token is invalid, the resource server returns
       an invalid token error.
  
  (G)  The client requests a new access token by authenticating with
       the authorization server and presenting the refresh token.  The
       client authentication requirements are based on the client type
       and on the authorization server policies.
  
  (H)  The authorization server authenticates the client and validates
       the refresh token, and if valid, issues a new access token (and,
       optionally, a new refresh token).

关于你的问题:

这是另一个JWT 刷新令牌可以存储在客户端的后端，这样用户就不能访问它。否则就必须加密。 是的

假设这是关于OAuth 2.0的，因为它是关于jwt和刷新令牌的…:

just like an access token, in principle a refresh token can be anything including all of the options you describe; a JWT could be used when the Authorization Server wants to be stateless or wants to enforce some sort of "proof-of-possession" semantics on to the client presenting it; note that a refresh token differs from an access token in that it is not presented to a Resource Server but only to the Authorization Server that issued it in the first place, so the self-contained validation optimization for JWTs-as-access-tokens does not hold for refresh tokens that depends on the security/access of the database; if the database can be accessed by other parties/servers/applications/users, then yes (but your mileage may vary with where and how you store the encryption key...) an Authorization Server may issue both access tokens and refresh tokens at the same time, depending on the grant that is used by the client to obtain them; the spec contains the details and options on each of the standardized grants

基于此实现的Node.js的JWT与刷新令牌:

In this case they use a uid and it's not a JWT. When they refresh the token they send the refresh token and the user. If you implement it as a JWT, you don't need to send the user, because it would be inside the JWT. They implement this in a separate document (table). It makes sense to me because a user can be logged in in different client applications and it could have a refresh token by app. If the user lose a device with one app installed, the refresh token of that device could be invalidated without affecting the other logged in devices. In this implementation, it response to the log in method with both, access token and refresh token. It seems correct to me.

智威汤逊有两个问题:

糟糕的标准化 很难撤销(用于身份验证时)

第一个问题可以通过使用你自己的JWT实现来解决:把你想要的任何东西放入JSON中，用AES加密——看——用它来进行身份验证(如果需要也可以用于授权:把角色放在JSON中)。

超简约JWT {"id": "<id>"}

第二个问题需要澄清。对于存储在服务器端的常规会话，不存在撤销问题:会话可以在任何时候由服务器使其失效。但是常规会话在可伸缩性和性能方面存在问题，因此出现了JWT。

撤销问题的常见解决方案是使用刷新令牌。

以下是如何做到这一点:

The refresh token can be the exactly same JWT as the access-token: custom JSON encrypted and base64 encoded. The result string can be just duplicated. If the access-token contains a lot of data (for example roles), the refresh token may be different as it needs only the user id. Both access and refresh tokens don't have any expiry hardcoded inside. They are both stored in https_only cookies but the expiration time for the access-token cookie is 2 min and for the refresh-token cookie is 30 min. Refresh-token stored in DB (User table) and can be easily revoked/invalidated by deleting from DB. Server looks for access-token in request: if presents and valid (can be decrypted) - OK process request; if the access-token does not present (cookie expired), the server looks for a refresh-token: if presents - validate by comparing it to one stored in DB and generate a new access-token (based on information from the refresh-token and DB) and process the request. If the refresh-token is not there, then the server looks for one of the following: username-password pair, third-party identity provider token (Google, Facebook, etc.), third-party identity management system token (Cognito, Okta, JumpCloud). If any are found: process the request and generate new access and refresh tokens. If nothing is found, then the server sends an authentication error and forces the client to relogin the user.