How do I use OpenID in my new ASP.NET website?

Question

I must be stupid, because all the articles I've seen on OpenID in ASP.NET have simply confused me on the issue. I'm pretty sure I understand the concepts involved here, I'm just a little fuzzy on how things look on the back end side of things.

So a new user comes to my website and wants to create an account. Here comes the flood of questions:

• Is the first step here to have him pick which openID provider he will use to sign in?
• Do I prompt him for a user name on my system?
• Do I need to tie him to the same openID provider each time he returns, or can he select a new provider each time?
• What does the database look like here? Do I have his username in a table and that is linked to an openID provider?
• What if the user doesn't have an OpenID account? Should I allow him to create a traditional account on my end, then expose myself as an OpenID provider?

What am I missing here? I'm usually pretty bright, but this area has been like kryptonite to Superman for my developer smarts. Thanks in advance!

Adam

Answer 1

This page is a step-by-step tutorial on implementing OpenId on a web site. I believe it will answer all your questions about the mechanics of adding it.

A Recipe for OpenID-Enabling Your Site

If the user doesn't have an OpenId I would just allow them to register 'normally', storing their credentials for local use. There is no need to add the extra complexity of becoming an OpenID provider unless you have a business case for that.

Answer 2

Dude, you're not alone. OpenID confuses everyone except the people who designed it, and even then, I'm not so sure it doesn't confuse them either since there are multiple OpenID providers and slight incompatibilities between them, depending on whose libraries you use.

Imagine the user is a sql "table" himself (that table contains his "credentials"), and you have a table of profile data specific to your website that you own. The OpenID url is a "foreign key" that you use to "join" these two tables. You must prove to yourself that he really owns that OpenID url before accepting it (or associating it with your private profile data). You're essentially "offshoring" the authentication portion of your site.

So ultimately, you use an openid client library that does the work for you on your website. They register as normal filling in "full name, "age," etc (whatever you want) but they provide an openid url instead of username/password. The library looks after verifying they really own it. You have to trust this library to do that. You then store all of your profile data with that openid. Done.

While you could offer your own openid provider, it's not worth it at this point. There are plenty out there already. What you could do though, is offer a traditional username/password INSTEAD of openid. The idea of openid is that your register ONCE with a provider, and then just prove you own that URL to any site that wants to use it to identify you (instead of username/password).

Make sense?

-Oisin