使用带有 angular 2+ 的社交登录时,信息以何种方式在组件之间传递?

In what way is the information passed between components when using social signin with angular 2+?

我计划通过以下方式为我的应用程序支持多个登录选项(包括使用 google 和 facebook 进行社交登录)。 当用户点击使用 google/facebook 登录时,一个新的 window 打开,用户身份验证完成,服务器 returns JWT, 我存储在本地存储中并使用 hostlistener,前一个window(或父window)知道认证成功

此流程运行良好(通过正常的服务器端身份验证),但我正在考虑将 JWT 存储在本地存储中可能引起的安全问题。使用社交登录时共享身份验证信息的标准方式是什么?

是否有更好的方法将 JWT/authentication 详细信息从子 window(进行身份验证)传递给父 window? 另一种选择是使用 Eventemitter 在两个组件之间传递信息,但是使用社交登录和 jwt 的网站使用的标准方式是什么?

编辑: 我想复制大多数网站所做的行为,即当用户通过身份验证时,父 window 保持静止并且一旦身份验证完成并传递给父级 window,它重定向到主页或重定向 url。

如果您真的想使用弹出窗口 window 进行身份验证,您可以使用

从弹出窗口访问应用程序的父级 window
window.opener

从弹出窗口向父级发送令牌的最简单方法是 post 一条消息(参见 Mozilla docs

window.opener.postMessage(messageContainingToken, window.location.origin);

父window需要有一个监听器

window.addEventListener("message", receiveTokenMessage, false);

function receiveTokenMessage(event) {
   if (event.origin !== window.location.origin) {
       return;
   }
   let messageContainingToken = event.data;
}

messageContainingToken 可以是令牌本身或一些更复杂的 JSON。然后可以将token存放在SessionStorage中,比LocalStorage更安全

更新(建议):

我建议您不要使用弹出窗口 window。相反,在登录页面上,我会为 "Login with SomeOauth2Provider" 创建按钮。当用户单击该按钮时,他将被重定向到 SomeOauth2Provider 网站,经过身份验证后,他将被重定向回您的 Angular SPA(您提供 redirectUri)。处理包含令牌的 redirectUri 的 Angular 组件将验证令牌,将其保存到 SessionStorage 并将路由更改为应用程序的某个初始视图。

我认为在重定向后再次加载您的 Angular 应用程序比打开一个新的 window(也可以禁用)更加用户友好。

我建议使用 firebase。他们有 angular 的软件包,生产就绪的社交登录实现。看看:https://firebase.google.com/products/auth/

有一篇关于使用 firebase 为 angular 应用程序验证用户身份的好文章:https://medium.com/@hellotunmbi/step-by-step-complete-firebase-authentication-in-angular-2-97ca73b8eb32

我的建议是将集中状态管理@ngrx/store一起使用,这样你就拥有了JWT和用户存储在应用程序状态中的声明可以从应用程序的每个部分使用它。

以下链接可能有助于启动:

https://auth0.com/blog/managing-state-in-angular-with-ngrx-store/

https://github.com/ngrx/platform/blob/master/docs/store/README.md

https://blog.angular-university.io/angular-ngrx-store-and-effects-crash-course/

然后您可以使用 HTTPInterceptor 将令牌添加到 headers。如果您使用像 angular-oauth2-oidc 这样的 OAuth 库,您不必担心这一点,因为它带有自己的拦截器,但如果有拦截器,您应该取消提供自己的拦截器。

localStoragesessionStorage 都扩展了存储空间。除了 sessionStorage.

的预期 "non-persistence" 之外,它们之间没有区别

也就是说,存储在 localStorage 中的数据一直存在,直到被明确删除。所做的更改已保存并可供所有当前和将来访问该网站。

对于 sessionStorage,更改仅适用于每个 window(或 Chrome 和 Firefox 等浏览器中的选项卡)。所做的更改已保存并可用于当前页面,以及将来在同一 window 上访问该站点。 window 关闭后,存储将被删除。

Web 存储 (localStorage/sessionStorage) 可通过同一域上的 JavaScript 访问。这意味着您网站上的任何 JavaScript 运行 都可以访问网络存储,因此可能容易受到 cross-site 脚本( XSS) 攻击。 XSS,简而言之,是一种漏洞,攻击者可以在其中注入 JavaScript,从而 运行页。

使用 Cookie 代替!!! Cookies,当与 HttpOnly cookie 标志一起使用时,无法通过 JavaScript 访问,并且不受 XSS。您还可以设置安全 cookie 标志以保证 cookie 仅通过 HTTPS 发送。