现有的mvc 3应用程序正在使用asp.net成员身份验证（System.Web.Security.MembershipProvider的子类）。此应用程序仅使用Web浏览器访问。
现在，应用程序需要支持移动应用程序，我已经在项目中引入了WebApi 2控制器来处理移动应用程序请求。
问题是我没有清楚地想过如何验证移动应用程序用户。
似乎我必须提供令牌类型的身份验证机制，其中移动应用必须提交每个请求的令牌（在身份验证后发布）。但我不确定如何实现它（比如要使用的框架/包），并使其与现有的 MembershipProvider
并行工作那么，我如何提供一种验证Web Api请求的方法，并保留现有的用于MVC Controller请求的asp.net MembershipProvider。
另外，如果可以通过其他方式做得更好吗？
答案 0 :(得分：2)
它不一定是＆＃34;令牌＆＃34;验证移动用户。
用于验证webapi请求的令牌的概念受到了很多关注，因为DotnetOpenAuth和OWIN已经采用了.NET世界的OAuth2协议。 OAuth2支持多个＆＃34;流＆＃34;而有趣的是旁边＆＃34;被动＆＃34;流（浏览器重定向到外部登录页面）还有＆＃34;活动＆＃34;流（专为移动应用等活跃客户设计）。
因此，切换到OAuth2意味着您正在使用支持所有主要方案的一致认证协议。
对您而言（您似乎感兴趣）的一种可能方法是采用令牌方法来验证webapi请求。这是可能的，但这意味着您可以并排使用两种不同的身份验证方法，即针对被动客户端的基于cookie的表单身份验证和针对活动客户端的基于令牌的身份验证。
我会说这种气味。
我宁愿考虑采用统一的方法。
完全转向OAuth2，这意味着您为被动和活动客户端采用DotnetOpenAuth / OWIN。
或者您坚持使用表单身份验证，并为您的活动客户端启用它。
后者相当简单。您的活动客户端不携带令牌，而是携带表单身份验证cookie。要发布此类cookie，您只需公开一个匿名的webapi方法，该方法需要登录名和密码，并将表单cookie附加到响应中。
假设您的客户支持cookie，服务器发布的表单cookie将用于连续请求，您所要做的就是通过Web api方法获得Authorize属性。表单模块将获取cookie并在请求的生命周期中填充IPrincipal，就像它对常规请求一样。
总结：
转向基于令牌的身份验证：
优点：
缺点：
坚持使用表单身份验证：
优点：
缺点：