我们已经有了自己的数据库，users、roles、userrole表已经就位，并且刚刚在.net中发现了Identity系统。我想集成应用程序cookie身份验证，但很难理解此身份模型中的不同概念。不一定需要允许集成到第三方的OWIN适配器。由于我们不需要与第三方集成，我们只需要从系统中进行内部加密cookie验证，这就是我们真正想要的。
有人能帮我理解这些模型背后的概念吗？我读过每一本书，但仍然对它们感到困惑。
目前，我看到了许多身份模型：Users, Logins, Claims, Roles
- 我的
roles表会使用Roles还是Claims模型 - 有
Logins和Users，但我们每个用户只有一个登录名。在这种情况下该怎么办 - 我需要使用OWIN吗？我不需要第三方集成，而且它看起来真的很重
- 如果用户具有某些任意属性（头像、年龄等），这些属性将存储在哪里
- 关于将我们自己的表/结构集成到Identity模型中，还有其他建议吗
启动应用程序创建的示例表比需要的要复杂得多。由于我们不需要太多功能，当然它们已经存在了，但需要2-表单身份验证、短信验证等。并不需要全部。这是一个内部系统。
上周我一直在努力掌握这个模型，但仍然遇到了麻烦。如果有人能为我指明正确的方向，那将是有帮助的。
用户非常直率，所以我们将跳过它。登录是外部身份验证附件。根据Identity与第三方身份验证提供商的工作方式，您可以拥有没有附加用户的登录、没有附加登录的用户或有附加登录的人。这是通过您的网站进行身份验证（登录）和成为您的网站的注册成员（用户）之间的区别。
声明只是与用户相关联的数据。通常，这些都是暂时的——永久存储在用户身上是没有意义的。例如，过期的第三方身份验证令牌在数据库中实际保存给用户是没有意义。
角色只是权限集。人们对角色有不同的看法，但从技术上讲，角色只是定义了用户可能具有的一些能力，如"CanEdit"、"CanView"、"CanDelete"等。你经常会看到人们更多地将它们作为组使用："Admin"、"Editor"、"Contributor"等，抽象地定义用户权限。
OWIN是Identity的核心组件。这不是你可以选择的。如果你不想使用第三方身份验证功能，那就不要使用，但包含它不是问题。
最后，身份是相当固执己见的。可以将您的用户数据迁移到特定于Identity的结构中，但实际上不可能让Identity只使用现有的用户表。我不确定这是否是你真正的意思，但如果是，那就别提了。你可以自定义各个身份模型，以便在数据库中包含更多信息，但通常情况下，如果你想使用Identity，你需要找到一种方法，将你的数据映射到Identity提供的内容中。