首页 文章

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

提问于
浏览
2

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

  • 第三方Oauth提供商,或

  • 电子邮件ID和密码 .

For point 1, I get it that

  • 格兰特类型为"Authorization code" .

  • 我的网站会将用户重定向到第三方Oauth提供商

  • 我将获得授权码,然后使用代码访问令牌 .

For point 2,

  • 我将主持一个Oauth服务器

  • 我不想将用户重定向到其他页面,因此"authorization code","client credentials"和"implicit" grant类型不是我要找的 .

  • 这让我留下"Resource owner password credentials" .

  • 如果我使用"Resource owner password credentials"我必须将客户端密钥暴露给Web应用程序,我听说这是一个坏主意 .

My query:

  • 在不将用户重定向到不同页面的情况下获取访问令牌的最合适方法是什么 . 目前,授权服务器是托管主应用程序的服务器 . 我希望这可以使用存储在我网站上的电子邮件和密码来验证用户

  • 如果"Resource owner password credentials"是要走的路,那么揭露客户端机密的安全隐患是什么 .

我是Oauth的新手所以如果我在任何地方都错了,请纠正我 .

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

谢谢 .

1 回答

  • 0

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

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

相关问题