Oauth 2.0获取访问令牌而不将用户重定向到不同的页面

时间:2017-07-03 08:56:09

标签: angular oauth oauth-2.0

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

登录我的网站
  1. 第三方Oauth提供商,或
  2. 电子邮件ID和密码。
  3. 对于第1点,我明白了

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

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

        1. 在不将用户重定向到其他页面的情况下获取访问令牌的最合适方法是什么。目前,授权服务器是托管主应用程序的服务器。我希望这可以使用存储在我网站上的电子邮件和密码来验证用户
        2. 如果要使用“资源所有者密码凭据”,那么暴露客户端密钥的安全隐患是什么。
        3. 我是Oauth的新手,所以如果我在任何地方都错了,请纠正我。

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

          感谢。

1 个答案:

答案 0 :(得分:0)

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

资源所有者密码流通常不是一个好主意,但可以在少数情况下使用。像守护进程应用程序或测试这样的东西都很好。一般来说,它非常脆弱,不会支持MFA或动态同意情况。而且,传统的隐式代码或授权代码流本质上不太安全。 Here's一篇很棒的博客文章,介绍在Azure AD(企业帐户身份提供商)范围内使用它的好案例。