如何设计数据库以支持OpenID

我正在考虑实现OpenID,但我在数据库看起来与新用户/现有用户的关系方面留下了空白.stackoverflow是如何做到的？我理解外部站点为我进行身份验证的概念,但就我的用户信息存储而言,我需要帮助.

Since this is one of the top search results when searching for OpenID Database Structures on Google, and the Plaxo link referenced in the previous answer is no longer around. I've copied and pasted the content of the Plaxo instructions below. I was able to get them by using the wayback machine page referenced here. Keep in mind that because of StackOverflow's 30000 character restrictions, I will have to crop certain sections, and Joseph Smarr included some images in his instructions, so you might want to look at the wayback machine page I referenced. -Jason

Prepared by Joseph Smarr at Plaxo on July 18, 2007.

This is a step-by-step tutorial guide for implementing OpenID consumer-side support with a web site that already has users with accounts. It will explain how to easily let new users sign up for an account on your site using their OpenID URL and how to let existing users attach their OpenID(s) so they can sign in using them.

我通过与Internet Identity Workshop和其他地方的OpenID开发人员交谈,以及使用这些说明为Plaxo实现OpenID支持,开发了本指南.我还发布了Plaxo实现的详细截图供参考.我打算让本指南清晰完整并遵循最佳实践,但如果您有任何问题或反馈,请告诉我ob_male('joseph','plaxo.com'); 或者通过在Plaxo的博客上发表评论.

本指南可能看起来有点长,但我希望你可以直接跟进它而不用多想,并且当你到达终点时你将完全完成!:)

概观

我假设您的网站目前有:

包含每个用户行的用户数据库

每个用户都有一个唯一的内部用户ID

用户当前使用用户名/电子邮件和密码登录

用于注册新用户和获取基本配置文件信息的注册流程

用于验证用户身份的登录页面

在内部,您可以根据用户名/电子邮件和密码对用户进行身份验证,查找其唯一的用户ID,并在您网站的其余部分使用它

用户管理其帐户信息的设置页面.

如果您的网站看起来不像这样,您仍然可以跟进,但某些部分可能与您无关.

Snipped ..所以检查上面的回路机器连接其余部分.

实施细节

安装OpenID使用者库

There are OpenID libraries already available in many popular programming languages that will do almost all of the heavy lifting for you. The team at JanRain wrote a bunch of them and are generally super-smart and knowledgeable when it comes to OpenID, so they'd probably make a good resource if you need help here.

根据库的不同,您可能需要为与OpenID提供程序站点的关联提供持久性存储.本质上,这只是存储从服务器/句柄字符串到关联字符串的映射.您至少需要为会话存储关联(以验证OpenID身份验证),但理想情况下您应该将它们存储更长时间,这样您每次重定向到OpenID提供程序时都不必重新关联(这样做会导致在更快的重定向).您可以使用memcached,数据库或您有权访问的任何其他永久存储介质.

创建一个新的OpenID数据库表

使用这样的模式(这将适用于MySQL,但如果您使用不同的数据库或者如果您以不同方式表示内部用户ID,则可能需要稍微调整一下):

create table user_openids (
  openid_url varchar(255) not null,
  primary key (openid_url),

  user_id int not null,
  index (user_id)
);

Keep a single global table so you can use it to look up OpenIDs for all your users (even if you have your users partitioned into multiple databases).

Store OpenID URLs in canonicalized form for robust lookup (i.e. so if users enter their OpenID slightly differently next time, you can still map it to their account). Most OpenID libraries will provide a canonicaliztion function, but briefly you should add http:// if it's missing and you should convert the protocol and domain to lowercase (but NOT the rest of the URL), so e.g. "WWW.AOL.COM/myOpenID" should be stored as "http://www.aol.com/myOpenID". You should also probably remove any trailing slashes from the URL.

If you usually have a layer of database-access code, you should expose the following functions to your application (in each case I've sketched the SQL to implement the function). As a reminder, all functions that take an OpenID as input should canonicalize it prior to looking it up in the database.

GetUserId(openid_url)
select user_id from user_openids where openid_url = openid_url

GetOpenIDsByUser(user_id)
select openid_url from user_openids where user_id = user_id

AttachOpenID(openid_url, user_id)
insert into user_openids values (openid_url, user_id)

DetachOpenID(openid_url, user_id)
delete from user_openids where openid_url = openid_url and user_id = user_id

DetachOpenIDsByUser(user_id)
delete from user_openids where user_id = user_id


Add OpenID UI to your registration page

Add a section to your registration page where OpenID users can sign up using their OpenID. The UI goal should be that OpenID users can easily identify that your site supports OpenID, but that users without OpenID can continue to register normally without being confused. You can either put an OpenID input box directly on the page or link to an OpenID page where users can enter their OpenID.

Wherever you put it, you should follow the community standards for naming and styling the text field where users enter their OpenID:

Use "openid_url" as the ID and name attributes of the text field (this will allow plug-ins to easily identify and handle OpenID input boxes across different web sites)

Add the small OpenID logo as a background image to the text box, using CSS like this:

background: #FFFFFF url('/images/openid-icon-small.gif') no-repeat scroll 0pt 50%;
padding-left: 18px;

It's also a good idea to provide a brief explanation of what OpenID is and how your users can use it on your site (since you'll probably get curious people clicking through to take a look).

Wrap the OpenID text box in a form that will submit to your OpenID login CGI, which we'll build below.

Upon providing an OpenID and signing in to the OpenID provider, you'll need to redirect your user back to your registration page with a couple of small tweaks. First, you should show the OpenID that the user is registering with, preferably with the small OpenID logo next to it to consistently identify it as an OpenID (see the screenshots below for an example). Second, you should NOT ask the user for a site-specific password, since they'll be signing in with their OpenID. So hide the password fields and make sure your registration code will allow this (you may need to stick in a random password behind the scenes if your code requires some password text, just don't show it to the user). [Note: it's fine to let users enter a site-specific password later by using your account settings page, but the point here is that one of the major benefits you're providing OpenID users is that they no longer need to maintain separate credentials for each site they use.]

Here are some screenshots of how we added OpenID to Plaxo's registration flow:

Add OpenID UI to your signin page

Add a section to your signin page where OpenID users can sign in using their OpenID. This will work both for existing users of your site that have attached an OpenID to their account and new users, who will be able to sign up using their OpenID (using the same flow as above). Like with the registration page, the UI goal should be a balance between being obvious to OpenID users without overly distracting or confusing the rest of your users. You should name and style your OpenID box as specified above in the registration page. And like above, the form surrounding the OpenID input box should go to the OpenID login CGI you're about to build.

In addition to your main signin page, you may also have signin UI in your home page or elsewhere. You should ideally provide an option to sign in using OpenID in every place you provide a traditional signin option.

Here are some screenshots of how we added OpenID to Plaxo's signin pages:

Create a new OpenID login web page/CGI

Your CGI should take two basic input (query) parameters:

openid_url: the OpenID entered by the user (for registration, signin, attaching, etc.)

action_type: the operation the user wants to perform. Possible values will be login, complete, attach, list, and delete. (If you're using Rails or a similar system, these could also be controller methods and thus part of the URL itself.)

Implement the login action (this is where the UI you added to the registration and signin flows will both submit to)

Look up the provided openid_url using the GetUserId function described above.

If the OpenID is already attached to a user in your system, check to see if the user is currently signed in to your site.

If the user is not signed in, they are attempting to sign in as an existing user, so prepare to redirect to their OpenID provider, but set a flag to NOT ask the provider for registration info (since the user is not signing up for a new account).

If the user is already signed in, and this OpenID already belongs to them (i.e. the OpenID URL is mapped to the same user_id as the currently signed-in user), then you don't have to do anything (this user is already signed in and already attached that OpenID, so this is a no-op). This is an edge case.

If the user is already signed in but the OpenID belongs to a different user, show an error message saying that this OpenID has already been claimed by another user. You can also provide the user the option to sign out and try again. This is an edge case.

If the OpenID is NOT currently in your database, the user is trying to sign up for a new account, so prepare to redirect to their OpenID provider and ask for registration info.

Save the provided openid_url in your session, since you'll need it to remember it when the OpenID provider redirects back to you, and the provider may not return it to you. If you don't have a session, you can use your database, but it has to be somewhere persistent and protected from user-tampering (i.e. not in a cookie or something that could be changed or forged by the user). 
(The reason you need to store the requested OpenID is that OpenID lets users delegate their OpenID to another provider behind-the-scenes. For instance, if I try to sign up with the OpenID josephsmarr.com, I may have actually delegated that URL to a different OpenID like jsmarr.myopenid.com, and when the provider returns to you to complete authentication, you need to remember that I wanted to sign up as josephsmarr.com and not jsmarr.myopenid.com. Luckily your OpenID library will most likely handle this for you, but you still have to keep the originally requested OpenID in your session for now. This may be solved in the upcoming OpenID 2.0 spec.)

Construct your return_to URL for the OpenID provider to return to after the user has authenticated. This will be your OpenID login CGI with the complete action specified.

If you've determined above that the user is registering for a new account, decide what registration info to ask for. Most OpenID providers support the simple-registration extension, which is a list of common registration fields that you can request as required or optional for your site, including full name, e-mail, nickname, gender, date of birth, gender, postal code, country, language, and time zone. If you ask for these fields and the user consents to provide them, you can pre-fill them into your registration flow, thus removing time and friction from your registration process. If your OpenID consumer library doesn't natively support requesting simple-registration parameters, see if they have a general facility for supporting extensions, or worst-case you can manually add it to the generated redirect URL before redirecting.

Call checkid_setup in your OpenID library to generate the URL to redirect to the user's OpenID provider. Pass in the (canonicalized) OpenID provided by the user and the return_to URL you constructed above. Also pass in the simple registration info you want if appropriate. Depending on your library, you may need to trap and handle some errors from this function. But assuming everything goes well, it will give you back a URL to redirect to.

Have your CGI redirect to the provided URL, ideally by issuing a server-side redirect response.

The user will be redirected to their OpenID provider's web site. They will be asked to sign in (unless they've recently signed in there), they will be asked whether they trust your web site, and if you've asked for simple registration info, they'll be asked what info they want to share with you. Once they complete this process, the OpenID provider will redirect the user back to the return_to URL you supplied, which will then let you initiate your complete action to finish the job.

Here are some screenshots of signing into an OpenID provider (myopenid.com in this case) and being prompted to share some registration info with Plaxo:

Implement the complete action (this is where the user gets redirected after signing in to their OpenID provider):

When the OpenID provider redirects to your return_to URL, they will add a bunch of additional query string parameters that contain the information needed to verify the user's authentication with this OpenID. Depending on the OpenID library you're using, you may need to gather these up into a data structure to pass in to the verification function, or it may do it for you.

Get the OpenID the user initially requested from your session (you stored it before redirecting to the OpenID provider above).

Call id_res in your OpenID library to verify the authentication data you've been sent by the OpenID provider. Pass in the OpenID that the user initially requested, along with the query parameters as needed. This function will check to see if everything looks valid. If you get an error back, display an appropriate error message to your user. Otherwise you've now confirmed that the user has authenticated the OpenID they provided to you.

Optional: after successfully verifying the OpenID, you may wish to set a persistent cookie for your site with the OpenID used so that you can recognize that the user has an OpenID next time they come to your site and pre-fill the OpenID box on the signin page. If you do this, make sure to also clear the cookie when the user explicitly signs out.

Look up the verified OpenID again using the GetUserId function. If you don't find it in your database, check to see if the user is currently signed in on your site. If they are, perform the attach action below to attach this OpenID to their existing account. Otherwise, it's time to start the registration process for a new account using this OpenID. Start by storing the verified OpenID in your session so your account creation code will remember the user has already verified this OpenID. (Do NOT use the same session variable you used to store the requested OpenID, since the user can type in anything there.)
Then redirect your user to your registration flow and pass along the simple registration data you got back (if any). You will probably have to map the fields returned by simple-registration to the registration parameters that your site normally takes.

As described above, the registration page should show the OpenID prominently in the account information, and you should NOT ask the user to enter a password for your site, since they'll be using their OpenID to sign in. In addition, you should pre-fill any registration info provided from their OpenID provider. It is fine to ask for additional registration info and maintain your current policies about which fields are required and optional. (Using OpenID should be an acceleration for registering on your site, but should not require you to change what information you require or otherwise change your site's normal behavior). Finally, you should provide a link for existing users of your service to attach this OpenID to their existing account, if they have one. This will handle the case of existing users that weren't signed in and entered their OpenID and have no found themselves in the new-user registration flow. [Since this isn't common, it's better to just have a small link at the beginning of the registration flow rather than asking every user "do you want to register a new account or sign in to an existing account" when they first verify their OpenID.]

When the user completes your site's registration flow and you create a user account, attach the verified OpenID to the newly created account using your AttachOpenID function. [If your user table and OpenID table are in separate databases and cannot be part of the same transaction, there is a small chance that the attach command could fail and leave you with an orphaned user account. There's no easy way to prevent this in 100% of cases, but since it's rare and the user can always sign up again, in most cases you can ignore this race condition and just hope for the best.

If you found that the verified OpenID was attached to an existing account, you can now sign the user in as you normally would if they'd signed in through your traditional method. (If the user happens to be signed in to a different account, sign them out and then sign them in as the user the OpenID is attached to, since they just proved they own it).

Implement the attach action (for existing users to attach additional OpenIDs to their account):

(This action will be called as part of the complete action when the user is already signed in and has just verified a new OpenID. So make sure the user is signed in before calling this action.)

Attach the verified OpenID to the signed-in user's account using your AttachOpenID function.

Show a confirmation message that this OpenID has now been attached and can be used to sign in from now on. Consider redirecting to the list action so the user can now see this OpenID among the list of attached OpenIDs for their account.

Here's a screenshot of Plaxo's attach confirmation page:

Implement the list action (for showing a signed-in user the OpenIDs attached to their account):

Require the user to be signed in (redirect through your signin page first if needed).

Fetch the list of attached OpenIDs for the signed-in user by calling your GetOpenIDsByUser function.

Show the list of OpenIDs in a web page with a link by each one to detach it if the user wants. The links will call the delete action below and pass in the OpenID to delete as the openid_url parameter.

Provide a link or input box to attach an additional OpenID. This will take the user through the l