单页应用程序（SPA--Angular）和身份验证最佳实践？答案

【问题标题】：Single Page App (SPA--Angular) and Authentication Best Practices?单页应用程序（SPA--Angular）和身份验证最佳实践？
【发布时间】：2014-05-14 02:45:50
【问题描述】：

我们正在研究将标准身份验证（登录）与我们的 Angular SPA 集成的最佳方法。我们遇到了两种模式（见下文），并想看看哪种模式被认为是一种“更好”的架构，可以将身份验证集成到我们的 Angular 网站中。

模式 1--保持登录与 SPA 分开（请参阅here）：在此模式中，登录过程在 SPA 之外完成（单独的页面加载），一旦用户通过身份验证，他们就会被重定向到 SPA（另一个页面加载）。

模式 2--将登录集成到 SPA（参见 here 和 here）：在此模式中，身份验证过程在 SPA 内，登录状态通过 Angular 路由器和服务进行管理。

我们倾向于 PATTERN 2，但我们希望从 SO 社区了解您的想法以及您如何比较这两种模式。

谢谢！

【问题讨论】：

【解决方案1】：

几个月前我也在考虑同样的问题，最后决定使用 SPA 解决方案中的登录。

我认为决定这两种方法的决定因素是您是否介意在用户登录之前加载完整的应用程序。

如果登录是 SPA 的一部分，则引导将在登录呈现给用户之前进行。这有两个缺点。首先，您加载了很多甚至可能不需要预先加载的 js、css 等。其次，您允许未经授权的用户访问您的代码。我认为这两个都是小问题，因为它们都可以解决，但仍然需要考虑。

如果登录与 SPA 分开，它会给您带来维护开销，因为您必须在应用程序之外维护一些东西，并且还需要与您的应用程序集成（例如主题、徽标、字体等）。但话又说回来，Gmail 正在这样做：P

我不知道您使用的是什么服务器技术，但是 ng-conf 的 google 演示为上述问题提供了一些很好的解决方案（不幸的是，当这个问题出现时我已经实现了我的解决方案）

【讨论】：

“我认为这两个都是小问题，因为它们都可以解决” - 如何准确解决第二个问题？我和 OP 有同样的问题，在我看来，我们会考虑在用户通过身份验证之前将所有代码交给用户，这似乎很疯狂。
您应该将您的客户端代码视为公共代码和开源代码。您不能在客户端代码中保留任何秘密或 IP。在绝大多数情况下，试图将您的客户端代码隐藏在登录页面后面不会让您走得太远。随意这样做，但如果你这样做，它不应该给你一种虚假的安全感。
我明白了。因此，即使需要一个有效的令牌来从服务器请求该内容，该内容仍然不安全吗？别人怎么能得到它？