Why does a web site operator need to trust an openid provider?

Question

I am working on a web site and am considering using OpenID for authentication. The site will have some low cost ($3-$5) premium services, but will not be protecting particularly sensitive user data, just saved game state. From my point of view, my main concern for authentication is that the person who paid for those services is the same person using those services. I don't care about verifying that user belongs to a particular email address or other public identity.

What risks do I open myself up to if I allow using johndoeblog.com/openid versus a well-known provider like Google? Perhaps the user himself trusts his own private server more than Google? Why should I force him to trust the same auth providers I trust?

The one factor I can see is the user either voluntarily sharing his credentials or them being compromised, thus allowing multiple people to access the premium services, but that's a problem I have to mitigate no matter what auth provider I use. What am I missing here?

Answer 1

Basically, you don't need to trust an OpenID provider: the user does.

Let's compare, from the strict perspective of authentication, passwords with OpenID.

• Password: User: “hey, server, it's me! You know it's me because no one else knows the magic word correcthorsebatterystaple, which I told you when I created the account.”
• OpenID: User: “hey, server, it's me! You know it's me because johndoeblog.com/openid says it's me, and I told you to trust johndoeblog.com/openid when it says it's me when I created the account.”

In both cases, as a server, you rely on the user's willingness and ability to choose a reliable authentication method. With passwords, the user must choose a password that nobody else knows. With OpenID, the user must choose an OpenID endpoint that nobody else can use.

For authentication purposes, there is no reason, as a server operator, to prefer one OpenID provider to another. You may (or may not) prefer to recommend OpenID providers who you know to be reliable, but you do not need to trust the OpenID provider in any way to authenticate the user.

Both cases rely equally on the user's cooperation to ensure that the user who paid is the one who uses the service. A password-authenticated user can share their password; an OpenID-authenticated user can allow the use of their OpenID endpoint.

All this is because you only care about the user's identity as account #1234 on your server. It would of course be completely different if you wanted to know that the owner of account #1234 is known as Joe Bloggs to the government of Syldavia: then you would need to trust the OpenID provider to provide you with Joe Bloggs's real name.

One minor reason to trust an OpenID provider is to offload the work of limiting account creation rates: if you know that Myriad has measures in place to restrict the account creation rate, and you only accept Myriad OpenID accounts, then this automatically restricts the account creation rate for your service. This doesn't apply to you: given that you're running a for-pay service, account creation rate restriction is built in.