我正在为Javascript单页面应用程序探索JWT和OAuth2，它将调用后端服务器端API . 我提出了一个涉及使用两个令牌的安全流程，并且为我提供了避免需要额外的服务器端会话存储的优势：
-
第一次加载客户端JS应用程序时，用户将用户名/密码 over SSL 发送到OAuth2服务器 . 服务器将设置一个cookie（客户端可读的普通cookie，不设置任何HttpOnly标志），其中包含一个内部有OAuth2访问令牌的JWT 's claims (along with some other non-confidential data in the JWT claims, ie. user' s姓/名，国家/地区，角色/权限） . 服务器还将设置一个包含OAuth2刷新令牌的HttpOnly cookie .
-
服务器设置的cookie将自动包含在客户端的每个请求中（始终通过SSL），因此服务器将收到JWT（请参阅步骤3）并确认签名并确认OAuth2访问令牌 . 服务器还将确认刷新令牌 . 由于服务器在每个请求上检查访问令牌并针对OAuth2数据库刷新令牌，因此这使我们能够撤销访问权限（我们无法单独使用JWT签名） . 我们可以做一个撤销访问和刷新令牌的"hard"撤销 . 我们可以执行"soft"撤销，它只撤销访问令牌（对于我们保留在JWT声明中的某些数据可能会更新的情况，即用户更改其名称或国家/地区或角色） . 软撤销对于客户端最终用户是不可见的（它不会破坏其登录状态） .
-
在上面的步骤2中，服务器将 actually 在客户端设置的特定标头中查找JWT（而不是服务器设置的cookie） . 例如，客户端JS应用程序将从cookie中读取JWT，然后在标头的另一部分中设置JWT . 通过要求客户端显式设置包含JWT的头文件密钥/值，显示客户端能够读取它自己的cookie，从而防止XSRF（跨站点请求伪造） .
-
包含刷新令牌的HttpOnly cookie确保我们受到XSS保护（即一些潜入我们客户端的恶意javascript） . 如果我们的JWT被盗，仍然不会授予访问权限，因为JS也没有看到或窃取刷新令牌 .
通过这种方法，我们获得了所有这些好处
-
We don't need a server-side session storage . 由于我们正在访问OAuth2服务器，因此我们可以简单地在JWT中包含一些我们返回的额外数据（非机密数据） . 我们不会't need to re-query/refresh the data in the JWT every time, but perhaps only when the OAuth token is revoked (ie. was revoked when some user data was changed that we include in the JWT' s） . 无需解决使用会话带来的存储/扩展要求 . 客户端JS应用程序可以像任何其他应用程序通常使用会话一样使用此数据 . 例如，我可以在应用程序的每个"page"上显示用户的名字 . 我们也可以使用websockets，但JWT是一个很好的备份位置，可以在需要时添加一些数据 .
-
We are protected against XSRF .
-
We are protected against XSS.
-
We can revoke access and also log users out （单凭JWT不容易实现） .
-
SSL 可防止中间人攻击 .
-
The JWT adds a little extra security hurdle for attackers to pass versus just a normal JSON object serialized in the cookie. 攻击者需要获取用于签署JWT的服务器端密钥（除了OAuth访问权限） . JWT也是一种标准，因此可信赖的开发人员更容易使用 .
-
The JWT can be easily passed down to other micro-services sitting behind the OAuth layer to use service-to-service . 我们可以将它作为"session like"数据访问传递给请求中的所有服务 . 如果服务想要's to change something in that data, then they can inform OAuth2 server and it will 2710535 revoke the user'当前的JWT（与会话存储的过程没有太大的不同）并提供一个新的 .
我还没有详细说明 . So my question is, does this approach indeed provide the benefits I listed above? If not, what am I missing here and what security hole have I not covered for?