REST或GraphQL单页应用程序的安全身份验证

Question

我正在开发一个带有GraphQL后端的新SPA。我不确定的是如何正确解决JS客户端和GraphQL后端之间的身份验证。出于身份验证的目的，后端是GraphQL还是旧的REST并不重要。

我在StackOverflow上阅读了一些文章和其他问题。以下是我收集的可能解决方案及其问题：

缓存

当然，Cookie很容易受到CSRF攻击。因此，cookie可以与一些额外的CSRF保护一起使用。在这种情况下我找不到如何实现它。如何在SPA中创建和使用CSRF令牌？

JWT（JSON Web令牌）

显然JWT有很多问题，不应该使用：

• https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid
• http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
• http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/

其他一些令牌

这是大多数REST API的作用 - 客户端通常在X-Auth-Token标头中发送身份验证令牌。这当然没有Cookie的CSRF漏洞，但并不完全适合SPA（REST API通常不是为SPA前端应用程序设计的）。它与JWT共享一些问题 - 主要是令牌需要存储在客户端的LocalStorage中。 （在article中解释了上面链接的JWT。）

问题在于我总是发现一些批评，为什么解决方案X错误，没有信息要使用什么信息，或建议使用解决方案Y而不考虑解决方案的问题。

许多网站都说API应该是无状态的 - 不保存有关当前经过身份验证的会话的任何数据，因为它会阻止水平扩展。我并不真正分享这个问题 - 99％的应用程序无论如何都不需要水平扩展。

那么SPA身份验证的最佳做法是什么？您在SPA中使用了什么解决方案？

我不一定无视上面列出的所有解决方案，但如果应该使用其中的任何一种，我需要以某种方式解决他们的问题，或者有充分的理由忽视这些问题。

Answer 1

在身份验证方面，有很多非常聪明但愤怒的人与任何概念进行斗争，而且你是对的，他们常常会忘记他们应该推荐替代品的部分。

OAuth 2已被许多人所诟病，但只要您使用SSL，它确实非常棒！

有一整章解释了我所有认证类型的优缺点：Build APIs You Won't Hate