登录后验证Json Web令牌和重定向

Question

我最近阅读了Angularjs的Cookies vs Tokens,并实现了登录和身份验证部分,允许用户从登录页面登录.该应用程序设置为将帐户模块(负责登录,帐户注册,配置文件等)作为单独的页面,该页面将重定向到主应用程序的SPA.

成功登录后,令牌将作为JWT发送回登录页面客户端,并通过js设置sessionStorage/localStorage值.最后,用户被重定向(也通过js)到主应用程序.问题是因为我通过js重定向无法设置标头,这显然在加载页面时主应用程序中的auth失败(因为我的auth中间件高于静态和auth api请求).如果我尝试在表单发布后从服务器重定向而不是通过JSON成功返回令牌,则不会通过博客帖子中描述的js设置sessionStorage.

我已经提出了一些想法,并希望得到一些意见,如果其中任何一个对最佳实践有益.

1. 从服务器设置响应验证cookie'仅限http'(我们所有的浏览器要求允许这个)cookie,在下一个主应用程序请求中读取.然后,服务器将读取cookie并允许提供安全的静态资产.我最初的想法是设置一个cookie,以便在每次请求时都使用Authorization标头,因为有时候即使在第一个api请求中删除了cookie,也可以读取cookie.

2. 允许前面提到的静态资产加载而无需身份验证(html,css,application js)和第一个内部API请求(在加载时几乎立即需要应用程序),然后通过Angular的$ http拦截器进行访问以设置请求授权标头.如果发送回401,则相同的拦截器可以重定向到登录页面.

我认为第二种方法是更简单的方法,因为只需要在静态文件中间件下移动auth中间件然后在Angular中更新http拦截器,但是认为让静态文件能够加载然后重定向可能是不好的做法事后.任何输入都表示赞赏.

Answer 1

针对你的第1点

...我最初的想法是设置 cookie 违背了在每个请求上使用授权标头的目的，因为即使在第一个 api 请求中删除了 cookie，有时也可以读取 cookie。

授权标头的使用并不意味着与 cookie 的使用相互排斥。我们的想法是在最适合问题的时候使用它，例如在单页应用程序和本机移动应用程序中。然而，由于它确实依赖于某种客户端存储，最好是 sessionStorage，因此如果像旧浏览器一样使用 sessionStorage 存在问题，建议有时使用 cookie 来存储令牌。因此，只要您使用 cookie 来存储令牌而不是进行身份验证，您就没有达到目的。请参阅后续文章中的 第 1 点https://auth0.com/blog/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/

如果您想知道“但是如果我将令牌存储在 cookie 中，我就回到了原点”。并非如此，在这种情况下，您使用 cookie 作为存储机制，而不是身份验证机制（即 Web 框架不会使用 cookie 来验证用户，因此不会发生 XSRF 攻击）