Question

我正在尝试为我的网站实施OpenID身份验证。这是场景：
我希望用户能够

使用openId登录（用户可以通过访问openid提供商进行验证。无需使用电子邮件密码创建自定义帐户），
通过电子邮件/密码（用户通过填写表格在网站上注册）
将开放式ID附加到他/她的帐户（openids +一个帐户的电子邮件）。

现在我不知道我应该为open id存储哪些凭据。并且不确定数据库架构。这是数据库模式：

Table: Users
UserId => PK
... => Custom info. Not related to authentication.

Table: Authentication  
AuthenticationId => PK
LoginId => (when custom site membership => email address) (when openId => openid unique address)

UserId  => FK to Users.
Provider =>(when custom site membership => "CUSTOM") (when openId => openid provider address)  
Password => filled when using custom membership. empty when using open id.

现在，当用户登录时，无论是使用openid /自定义成员身份，我只需查看身份验证表并查找凭据并获取相应的用户。如果没有用户，我创建一个新用户并在身份验证表中添加一个条目。

主要问题：存储Provider和LoginId（请参阅上述注释以查看这些字段中存储的内容）是否足以存储openid身份验证？我应该存储任何其他数据，以便在用户返回时我可以根据我保存的数据对他/她进行身份验证吗？
您是否建议采用其他（更有效）方法来实现此目的？谢谢。

Answer 1

为openid用户存储ClaimedIdentifier - 而不是提供商地址。声明的标识符是OpenID协议验证的，对用户来说是唯一的，也可能提供跨OpenID提供商的可移植性。

此外，由于OpenID Connect（OpenID 2.0的未完成后继者）可能不推荐使用OpenID 2.0的声明标识符，因此记录OpenID提供商端点URI和提供商声明的电子邮件地址也可能符合您的最佳利益。在用户记录中。现在，不使用这些作为您的身份验证流程的一部分，但通过记录它们，您将能够在以后确定您“信任”的电子邮件地址（即假设您决定由Google值得信赖，并允许用户使用经过验证的电子邮件地址将其帐户迁移到OpenID Connect。这还可以减轻您网站领域（通常为http://yourdomainname.com）的危险，并导致您的所有Google用户声明的标识符发生变化，这只能通过电子邮件地址真实地恢复。

我还建议您为不同的auth类型使用不同的表。这里有几个优点。最重要的一点是，从架构上来说，在您的网站中引入安全漏洞会更加困难，因为这可能允许某人将（例如）OpenID输入到用户名字段和空白密码中，并将其显示为数据库匹配和登录没有任何真正的身份验证发生。其次，它提供了一个更灵活的模型，以防您想要添加第三种身份验证机制，而不是让所有用户的“身份验证”表水平增长。例如，OAuth 2.0和“OpenID Connect”可能会在您多年来为您的网站添加支持时为您的网站引入新类型的身份验证，并且添加新表来处理新类型的数据似乎更适合。

Answer 2

我们只存储openid声明网址。您可能需要从提供商处请求其他信息，例如用户名。最重要的是分离成员身份和身份验证。

我们的架构是

Profiles
--------
UserId
FirstName
LastName
etc.

Users
-----
Username
Password

Profiles.UserId只是一个字符串属性，用于存储用户的内部用户名或其openId声明网址，具体取决于他们的注册方式。

成功验证（使用内部用户名/密码或外部提供商）后，我们只需使用其内部用户名或其声明网址设置其身份验证Cookie。获取用户的个人资料只需要找到探查器的位置（UserId == User.Identity.Name）。

这样做的好处是，用户可以选择更改他们在任何时候进行身份验证的方式（可能切换到内部帐户或使用其他提供商）。

存储必要的OpenID信息

2 个答案: