【问题标题】:Oauth Implicit Grant web api authorization serverOauth 隐式授予 web api 授权服务器
【发布时间】:2025-11-30 02:25:01
【问题描述】:

我正在查看以下隐式授权示例。

http://code.msdn.microsoft.com/OWIN-OAuth-20-Authorization-ba2b8783

我可以看到该示例如何将未经身份验证的用户重定向到同一授权服务器的登录页面。如下所示:

Client ---> AuthServer ---> 401
                             |
       <--- Login (UI) <------
            (On Auth server)           

我的问题是我不想授权服务器来处理登录页面的 UI 部分。那就是我的授权服务器是一个 web api,它唯一的工作是处理 owin 管道并通过 webapi 对用户进行身份验证。

理想情况下,我想做的是,授权服务器以 401 响应客户端。客户端(可以是纯 js 应用程序)显示登录页面(用户名/密码)并通过 SSL 和身份验证使用用户名/密码 POST 到授权服务器。服务器说你可以登录了。

这将使所有客户端都可以管理其登录页面的外观,但身份验证(逻辑)部分是通过身份验证服务器 webapi 完成的。

这可能吗? 实施此操作时是否需要注意任何安全隐患(仅针对此场景)?

谢谢

【问题讨论】:

    标签: security asp.net-web-api oauth authorization owin


    【解决方案1】:

    如果授权服务器的实现支持“Resource Owner Password Credentials Grant”并允许您的应用程序使用它,您就可以实现您的场景。但是,授权服务器不太可能这样做。

    OAuth 2.0 的主要目的是允许第三方应用程序(例如您的应用程序)访问最终用户(= 资源所有者)的受保护资源无需将最终用户的凭据(用户名/密码)传递给第三方- 派对应用程序。因此,您的场景正是 OAuth 2.0 试图避免的用例。


    [评论您的附加问题]

    如果您是授权服务器的实现者,是的,您可以同时实现“隐式授予”和“资源所有者密码凭据授予”。由你决定。另一方面,如果您是客户端应用程序的实现者,该客户端应用程序访问已由其他人(至少不是您)实现的授权服务器,您的客户端应用程序是否可以使用“资源所有者密码凭据授予”取决于授权服务器的实现。我的意思是,一般授权服务器实现不会给第三方应用程序使用“资源所有者密码凭据授予”的机会,因为这是最后的手段,规范 (RFC 6749) 说 "授权服务器在启用此授权类型时应特别小心,并且仅在其他流程不可行时才允许它。"

    【讨论】:

    • 嗨,我明白你在这里所说的,是的,它是可能的,但从 oauth 的角度来看它是反模式。 “但是,授权服务器不太可能这样做”是什么意思。我已经在身份验证服务器上实现了“隐式授予”和“资源所有者密码凭据授予”。你是说它应该只有一个?
    • 查看我添加到答案中的评论。