如何将OAuth与单页面应用程序集成？

Question

使用OAuth时（2）我的应用程序中需要一个重定向端点，一旦我通过身份验证，OAuth提供服务就可以重定向到该端点。

如何在单页应用程序中处理此问题？当然，重定向到提供OAuth的服务并不好，甚至可能无法重定向。

我知道OAuth还支持基于用户名/密码的令牌生成。这与AJAX调用完美配合，但要求我的单页应用程序要求输入用户名和密码。

你通常如何处理这个问题？

Answer 1

大多数情况下，即使对于SPA，重定向也是可以的，因为用户不喜欢将他们的X服务凭证放在除X之外的任何其他网站上。另一种方法是使用一个小弹出窗口，你可以查看{ {3}}。恕我直言，重定向比弹出窗口好。

Google 某些提供商支持Discourse，这就是您所说的发送用户名和密码，但这并不好。这些是我看到的问题：

1. 向您网站中的用户询问Google凭据对某些用户来说是不可取的。
2. 资源所有者流也需要client_secret，这是你不能放在客户端javascript中的东西。如果您从服务器端应用程序实例化资源所有者流，并且您的应用程序与用户不在同一地理区域，则用户将收到警告“嘿有人试图使用您的来自印度的凭据进行访问”。

OAuth描述了一个名为resource owner flow的客户端流程。使用此流程，您不需要在服务器端进行任何交互，也不需要client_secret。 OAuth提供程序使用“＃access_token = xx”重定向到您的应用程序。它被称为隐式，因为您不需要按访问令牌交换授权码，直接获得access_token。

Google实施隐式流程，请检查：implicit flow。

如果您想使用隐式流与某些不支持它的提供程序（如Github），您可以使用Using OAuth2 for Client-Side apps之类的身份验证代理。

免责声明：我为Auth0工作。

Answer 2

Answer 3

OAuth2有4个流，也称为授权类型，每个流都有特定的用途：

• 授权码（您提到的授权码，需要重定向）
• 隐含
• 客户凭证
• 资源所有者密码凭证

简单的答案是：使用隐式流。

为什么？选择流或授予类型取决于代码的任何部分是否可以保持私有，从而能够存储秘密密钥。如果是这样，您可以选择最安全的OAuth2流-Authorization Code，否则，您将不得不选择安全性较低的OAuth2流。例如，对于Implicit流的单页应用程序（SPA）。

Client Credential流仅在Web服务和用户是同一实体的情况下才有效，即，Web服务仅服务于该特定用户，而Resource Owner Password Credential流是最不安全的，因为用户需要向服务提供其社交登录凭据。

要完全了解建议的Implicit流和Authorization Code流（您提到的流并需要重定向）之间的区别，请并排看一下流：

此图摘自：https://blog.oauth.io/introduction-oauth2-flow-diagrams/