【问题标题】:AspNet Identity in hybrid MVC/Web Api controller Site混合 MVC/Web Api 控制器站点中的 AspNet 身份
【发布时间】:2015-05-07 12:47:52
【问题描述】:

我有一个同时使用 mvc 和 web api 控制器以及 aspnet 身份的站点。我使用带有 mvc 和 web api 控制器的 VS2013 SPA 模板作为起点。

这是我的场景:

用户使用 mvc 控制器登录并取回一个 auth cookie。

使用经过身份验证的 mvc 控制器提供下一页。该页面使用敲除并对 ​​Web api 控制器进行 ajax 发布调用,该控制器通过按钮单击(保存)进行身份验证。 Web api 控制器需要带有 Bearer --token-- 的 Authentication 标头。

我的问题是其他人如何处理这种“两种”身份验证方法。我在 mvc 控制器上创建了一个端点,该端点经过身份验证并根据当前主体返回一个不记名令牌。我可以使用该令牌成功发布到 Web api 端点。

我正在创建的 JavaScript 逻辑有点……令人困惑。它检查访问令牌是否在会话存储中,如果是,则进行 ajax 调用。如果没有,请调用 get token 端点,然后调用 web api 端点(使用一堆回调来处理 Ajax 承诺完成、失败等)。

其他人如何处理您需要身份验证 cookie 和承载令牌的场景,以便每个“mvc”页面都经过身份验证,并且页面调用的 Web api 端点也经过身份验证。如果不记名令牌在 cookie 过期之前就过期了怎么办。

如果我不清楚或者您需要更多信息,请告诉我。

编辑

我遇到了这个,Using bearer tokens and cookie authentication together 它仍然没有回答我的问题,因为我已经设置了它,所以 mvc 接受 cookie auth 并且 web api 只接受不记名令牌。我觉得这应该是一个已经解决的问题,但也许我采取了错误的方法。

【问题讨论】:

  • 您是如何解决这个问题的?我完全按照您对过去项目的描述做了,但我刚刚开始一个新项目,我很想知道这次我是否可以实施任何“最佳实践”
  • 我通过对 mvc 控制器进行所有 ajax 调用来解决这个问题。试图同时兼顾基于 cookie 的令牌和不记名令牌太复杂了。我们的网站只使用 mvc 控制器,我们的外部世界使用 web api。我将大部分“可重用逻辑”保留在一个通用业务层中。我仍然很想看看其他人采取了什么方法。

标签: asp.net-mvc asp.net-identity asp.net-web-api


【解决方案1】:

我认为您基本上偶然发现了OAuth2.0 的核心问题。 OAuth2.0 只是一个授权协议。您需要的是一个同时支持身份验证授权的安全模型。

介绍OpenId Connect

OpenId Connect 是建立在OAuth2.0 授权层之上的认证层。它提供了一种基于在后台服务器/服务上执行的身份验证来验证最终用户的简单方法。此外,它能够将有关用户的基本配置文件传递给 RESTful HTTP API 以使用 JSON 进行授权。

"OpenId Connect 允许一系列客户端,包括基于 Web、 移动和 JavaScript 客户端,用于请求和接收信息 关于经过身份验证的会话和最终用户。规范套件是 可扩展,支持可选功能,如加密 身份数据、OpenID 提供者的发现和会话管理。” -Wikipedia

对于 .NET,Identity Server 组件有一个 Nuget 包,名为 IdentityServer3。关于如何让一个简单的 MVC/Web-API 与 IdentityServer3 一起运行,有一个相当深入的 getting started tutorial

Web 应用与 Web API 和 Cookie 与令牌

  • 通常,Web 应用程序是使用基于 cookie 的身份验证的传统服务器端应用程序。

  • 另一方面,Web API 代表了一种新型应用程序,通常是单页应用程序(如 Angular、Ember、Backbone 等)或原生移动应用程序(如 iOS、Android 等)。 ) 使用 API(用 Node、Ruby、ASP.NET 甚至这些的混合编写)并将受益于基于令牌的身份验证。

您可能想阅读这些文章以了解更多上下文:Cookies vs Tokens. Getting auth right with Angular.JS10 Things You Should Know about Tokens

    1234563在每个请求中,都会发送该 cookie,并从某个存储(如果是单个服务器,则在内存中,如果是服务器场,则在某个持久存储中)对会话进行反序列化。
  • 基于令牌的身份验证是通过在用户进行身份验证时生成一个令牌,然后在对您的 API 的每个后续请求的授权标头中设置该令牌来实现的。您希望该令牌成为标准的东西,例如 JSON Web 令牌,因为您会在大多数平台中找到库,并且您不想自己进行加密。

  • 对于这两种方法,您可以从用户那里获得相同数量的信息。这由登录请求中发送的范围参数控制。

  • 您可以将基于令牌的身份验证与基于 cookie 的身份验证混合使用。考虑到如果 Web 应用程序和 API 是从同一个域提供的,cookie 就可以正常工作,因此您可能不需要基于令牌的身份验证。如果您想从 JavaScript 调用您的 API(而不是使用现有的 cookie),那么您必须以某种方式在您的网页中设置 id_token。一种方法是在布局/母版页上设置它,例如 window.token = ;然后您可以从 JavaScript 代码中的任何位置获取它。

P.S 这是一个很棒的video,主题是“通过 Dominick Baier 使用 OpenID Connect 和 OAuth2 统一移动、Web 和桌面的身份验证和委托 API 访问”。这应该有助于阐明 OAuth2.0 的局限性以及 OpenId Connect 如何尝试解决这些问题。

【讨论】:

    【解决方案2】:

    我已经设法通过使用 cookie 和刷新令牌解决了这个问题。

    就是这样,

    1. 在 cookie 中加密并保存访问令牌和刷新令牌。
    2. 在调用 web api 之前验证令牌到期日期。
    3. 如果令牌已过期,请使用刷新令牌/清除用户身份验证 cookie 获取新令牌并将其注销。

    我没有在VS2013 SPA模板中尝试过。 但正如我所见,您可以使用第二步来验证令牌,如果它已过期,请调用 mvc 控制器端点以获取新的访问令牌。

    【讨论】:

      猜你喜欢
      • 2012-03-10
      • 2015-04-25
      • 2016-10-06
      • 2014-01-31
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-07-12
      • 2017-05-23
      相关资源
      最近更新 更多