我们有一个现有的web应用程序，它是基于MVC&用于用户身份验证的SQL成员身份提供程序。该应用程序还包括用于创建/编辑用户、重置密码、激活帐户等的管理员管理屏幕。这是一个相当成熟的系统，已投入生产约2.5年。
我们现在有了一个新的要求，即通过API公开系统中的一些数据，我们将WebApi视为一种候选技术。
我遇到的一个问题是身份验证。我想利用我们应用程序中现有的用户/角色管理功能来创建和管理API帐户。然而，由于WebAPI的首选选项是使用ASP.NET标识（声明/承载令牌等），我对什么是最佳选项有点困惑。
以某种方式将现有会员资格提供商中的用户/密码身份验证引入web api auth mecs是否可能或是一个坏主意。ApplicationOAuthProvider中有一个方法，看起来我可以通过用对MembershipProvider的调用替换行IdentityUser user = await userManager.FindAsync(context.UserName, context.Password);来操作它。这似乎非常包含。
思想&我们将非常感谢您的选择。
不是一个真正的答案，只是我的0.02美分。
我认为您将花费与正确更新到新的Identity框架所需的时间一样多的时间来说服MembershipProvider加入新的Identity。
我在两个不同的系统中进行了升级，这两个系统都不小（一个是200K，另一个是70K代码行），用户数量增加了。较小的系统花了我7个工作日，较大的系统用了5天（我知道我第二次在做什么）。这两个系统都有大量的用户管理代码，其中一个系统可以为管理员模拟另一个用户。一切顺利，没有停机。用户没有注意到差异
但在升级后，使用用户管理/身份验证的事情变得容易多了，你很快就会花5天时间进行升级。把这看作一项投资-）
我看过MembershipProvider的源代码（在反编译器中），很多东西都是静态的、混乱的、密封的，而且完全无法管理。我想说，转储它会更容易，而不是构建更多的遗留代码，只是为了维护垂死的库。
换句话说，更新所有内容会更容易，而不是试图重复使用旧的东西。
这可以通过实现自己的UserStore来完成。我认为会有很多龙。你必须仔细考虑所有其他情况，并调和这两者：忘记密码、电子邮件确认、登录失败次数和时间跨度等等。基本上，更新用户数据的所有事情都必须仔细考虑，也许在每组表中都要加倍考虑。如果你可以将列添加到现有的成员资格表中，以支持asp.net标识的接口，这可能会有所帮助，但在某个时候，你最终会取消大部分数据访问部分，并实现一个完整的UserStore，而不是一个你主要委托给原始基于实体框架的代码的UserStore。
我想利用现有的用户/角色管理功能在我们的应用程序中，创建和管理API帐户。然而因为WebAPI的首选选项是使用ASP.NET标识（索赔/持有者代币等）我有点困惑什么是最好的
在单个项目中混合现有的SQL成员资格提供程序和Web API不是一个好主意。
在我的场景中，我创建了一个单独的Webneneneba API 2项目。然后，我创建了一个单独的类库项目，将IoC容器保存在一个位置，Web App和Web API都引用了该类库。
Web API项目仍然可以使用SQL成员身份提供程序的表。但是，您需要使用Membership Provider Encode Algorithm自己验证用户，并使用Claims自己创建IPrincipal对象。然后分配给Thread.CurrentPrincipal。
对于基于令牌的身份验证，您可以只使用JSONWebToken。
更新：如果您有更多时间，可以使用此示例将SQL成员身份直接迁移到ASP.NET标识。然后，您可以将MVC和Web API保留在单个项目中，因为它们都使用ASP.NET Identity。