我正在为Javascript单页面应用程序探索JWT和OAuth2，它将调用后端服务器端API。我提出了一个涉及使用两个令牌的安全流程，并且为我提供了避免需要额外的服务器端会话存储的优势：
- 第一次加载客户端JS应用时，用户将用户名/密码通过SSL 发送到OAuth2服务器。服务器将设置一个cookie（客户端可读的普通cookie，没有设置任何HttpOnly标志），其中包含一个带有OAuth2访问令牌的JWT，其声称（以及JWT声明中的一些其他非机密数据，即用户的姓/名，国家，角色/许可）。服务器还将设置一个包含OAuth2刷新令牌的HttpOnly cookie。
- 服务器设置的cookie将自动包含在客户端的每个请求中（始终通过SSL），因此服务器将收到JWT（请参阅步骤3）并确认签名并确认OAuth2访问令牌。服务器还将确认刷新令牌。由于服务器在每个请求上检查访问令牌并针对OAuth2数据库刷新令牌，因此这使我们能够撤销访问权限（我们无法单独使用JWT签名）。我们可以做一个“硬”撤销，撤销访问和刷新令牌。我们可以进行“软”撤销，只撤销访问令牌（对于我们保留在JWT索赔中的某些数据可能会更新的情况，即用户更改其名称或国家/地区或角色）。软撤销对于客户端最终用户是不可见的（它不会破坏他们的登录状态）。
- 在上面的步骤2中，服务器将实际在客户端设置的特定标头中查找JWT（而不是服务器设置的cookie）。例如，客户端JS应用程序将从cookie中读取JWT，然后在标头的另一部分中设置JWT。通过要求客户端显式设置包含JWT的头文件密钥/值，显示客户端能够读取它自己的cookie，从而防止XSRF（跨站点请求伪造）。
- 包含刷新令牌的HttpOnly cookie确保我们受到XSS保护（即一些潜入我们客户端的恶意javascript）。如果我们的JWT被盗，仍然不会授予访问权限，因为JS也没有看到或窃取刷新令牌。
通过这种方法，我们可以获得所有这些好处：
- 我们不需要服务器端会话存储。由于我们正在访问OAuth2服务器，因此我们可以简单地在JWT中包含一些我们返回的额外数据（非机密数据）。我们不需要每次都重新查询/刷新JWT中的数据，但可能仅在OAuth令牌被撤销时（即当我们在JWT中包含的某些用户数据被更改时被撤销）。无需解决使用会话带来的存储/扩展要求。客户端JS应用程序可以像任何其他应用程序通常使用会话一样使用此数据。例如，我可以在应用程序的每个“页面”上显示用户名。我们也可以使用websockets，但JWT是一个很好的备份位置，可以在需要时添加一些数据。
- 我们受到XSRF保护。
- 我们受到XSS保护。
- 我们可以撤销访问权限并注销用户（单靠JWT这是不可能的。）
- SSL 可防止中间人攻击。
- JWT为攻击者增加了一些额外的安全障碍，而不仅仅是在cookie中序列化的普通JSON对象。攻击者需要获取用于签署JWT的服务器端密钥（此外到OAuth访问）。 JWT也是一种标准，因此可信赖的开发人员更容易使用。
- JWT可以轻松传递到OAuth层后面的其他微服务，以使用服务到服务。我们可以将其作为“会话状态”传递给请求中的所有服务。如果服务想要更改该数据中的某些内容，那么他们可以通知OAuth2服务器并且它将“软”撤销用户当前的JWT（与会话存储的进程没有太大区别）并提供一个新的。
我还没有看到任何有关此类安全流程的详细信息。我看到的很多人似乎只谈到在内部使用带有OAuth2访问令牌的JWT，并且没有详细说明。 所以我的问题是，这种方法确实提供了我上面列出的好处吗？如果没有，我在这里缺少什么以及我没有涉及哪些安全漏洞？