Oauth 2.0 无需将用户重定向到不同页面即可获取访问令牌

Question

我想实现一个登录流程，用户可以使用

登录我的网站

1. 第三方 Oauth 提供者，或者
2. 电子邮件 ID 和密码。

对于第 1 点，我明白了

1. 授权类型为“授权码”。
2. 我的网站会将用户重定向到第三方 Oauth 提供商
3. 我将获得一个授权码，然后使用该码访问令牌。

对于第 2 点，

1. 我将托管一个 Oauth 服务器
2. 我不想将用户重定向到其他页面，因此“授权代码”、“客户端凭据”和“隐式”授权类型不是我想要的。
3. 这给我留下了“资源所有者密码凭据”。
4. 如果我使用“资源所有者密码凭据”，我必须向 Web 应用程序公开客户端密码，我听说这是个坏主意。

我的查询：

1. 在不将用户重定向到不同页面的情况下，获取访问令牌的最合适方法是什么。目前，授权服务器是托管主应用程序的服务器。我希望这可以使用存储在我的网站上的电子邮件和密码来验证用户
2. 如果“资源所有者密码凭据”是可行的方法，那么公开客户端机密会带来哪些安全隐患。

我是 Oauth 的新手，所以如果我在任何地方有错误，请纠正我。

注意：我的客户端应用程序是浏览器中的 Angular 2 应用程序。

谢谢。

Answer 1

您可以使用弹出式登录窗口通过隐式流程完成登录。这将加载身份提供者登录页面（/authorize 端点），但不会在您的浏览器中进行完全重定向。然后身份提供者可以设置适当的 cookie 并为您获取访问令牌。这是单页应用程序（角度、反应等）的规范模式。 Here's some reading 可以为协议增添一些色彩（在 Azure AD 的范围内，但其中很多都超越了身份提供者的实现细节）。

资源所有者密码流程通常不是一个好主意，但可以在少数情况下使用。守护程序应用程序或测试之类的东西是很好的案例。一般来说，它非常脆弱，不支持 MFA 或动态同意情况。此外，与传统的隐式或身份验证代码流相比，它本质上不太安全。 Here's 一篇很棒的博客文章，介绍了在 Azure AD（企业帐户身份提供者）范围内使用它的好案例。