如何在单页应用程序中实现OAuth2流程（Angular2 + Rails4）

Question

我想知道哪种OAuth2流最适合SPA方案。前端是有角度的，后端是有轨的。

我认为授权代码授权类型对于这种情况来说是最合适的，但我不确定当用户授予对我的应用程序的访问权限时如何处理重定向。该重定向打破了SPA精神，使用户保持在同一页面。

由于

编辑（补充资料）：

让我更准确一点。特别是我正在尝试使用此流https://developers.google.com/identity/protocols/OAuth2WebServer将Google日历集成到我的应用中。我面临各种各样的问题，其中大多数是因为我有一个角度SPA。

我的第一个问题是如何处理授权端点。到目前为止，我已经设计了名为/google_auth的端点，它将检查当前用户是否已授权该应用。如果没有，我将回复一个拥有authorization_uri的json主体。这是第一个问题，前端如何显示授权对话框。如果我呼叫window.open，浏览器将阻止它，因为它认为它是弹出窗口。如果我更改当前窗口位置，它将离开我的应用程序，我不想要这个。

当用户在google提供的授权窗口中授权我的应用时，会出现第二个问题。在这里，谷歌将发送带有授权码的请求到之前定义的重定向uri回调。当我使用JWT令牌进行身份验证时，在此请求中我丢失了哪个用户授予了我授权，因此我无法将刷新令牌与用户关联。我怎么处理这个？我想我可以使用state参数转发JWT令牌，但我不确定这是否足够安全

Answer 1

确实如此，但不要忘记为什么会这样。

重点是用户不会在未知的应用程序中输入密码，而且大多数人都不会。例如，当人们从Facebook看到登录页面时，他们会相信这一点并且很酷。一个随机的形式询问他们的密码并不酷，可能导致他们被黑客入侵，这就是为什么每个关心安全的人都会离开那个不安全的网站继续前进。

我的建议是坚持有意义的流程。一旦用户通过身份验证并为您的应用程序提供访问权限，他们就会被发送回您的应用程序，您可以在那里获得令牌并使用它进行进一步的工作，这样您基本上就可以回到SPA流程中了。只是你的流程现在有两个步骤，这就是全部。

Answer 2

基本上，您有2个UI选项：在同一窗口中打开授权页面，从而卸载SPA或弹出窗口，因此存在被阻止的风险。除非前端应用程序的状态太大，否则您可以存储必要的应用程序状态，通过授权，然后重新加载恢复状态的应用程序。状态可以存储在浏览器的localStorage中，重定向URL（如果协议允许可变部分）或服务器端。

Answer 3

如果您的应用程序位于公共场所，请在企业中遵循基于授权的流程，然后密码授予流程的第一个选项也可以。