OpenID providers - what stops malicious providers?

Question

So I like the OpenID idea. I support it on my site, and use it wherever it's possible (like here!). But I am not clear about one thing.

A site that supports OpenID basically accepts any OpenID provider out there, right? How does that work with sites that want to reduce bot-signups? What's to stop a malicious OpenID provider from setting up unlimited bot IDs automatically?

I have some ideas, and will post them as a possible answer, but I was wondering if anyone can see something obvious that I've missed?

Answer 1

You have confused two different things - identification and authorization. Just because you know who somebody is, it doesn't mean you have to automatically give them permission to do anything. Simon Willison covers this nicely in An OpenID is not an account! More discussion on whitelisting is available in Social whitelisting with OpenID.

Answer 2

The short answer to your question is, "It doesn't." OpenID deliberately provides only a mechanism for having a centralized authentication site; it's up to you to decide which OpenID providers you personally consider acceptable. For example, Microsoft recently decided to allow OpenID on its Healthvault site only from a select few providers. A company may decide only to allow OpenID logins from its LDAP-backed access point, a government agency may only accept OpenIDs from biometrics-backed sites, and a blog might only accept TypePad due to their intense spam vetting.

There seems to be a lot of confusion over OpenID. Its original goal was simply to provide a standard login mechanism so that, when I need a secure login mechanism, I can select from any or all OpenID providers to handle that for me. Allowing anyone anywhere to set up their own trusted OpenID provider was never the goal. Doing the second effectively is impossible—after all, even with encryption, there's no reason you can't set up your own provider to securely lie and say it's authenticating whomever you want. Having a single, standardized login mechanism is itself already a great step forward.

Answer 3

OpenId isn't much more than the username and password a user selects when registering for your site. You don't rely on the OpenId framework to weed out bots; your registration system should still be doing that.

Answer 4

Possible solution - you can still ask new IDs to pass a CAPTCHA test. Just like bots can sign up with fake/multiple email addresses to any site, but fail the "verification" step there as well.

Or are we going to have to start maintaining provider blacklists? Those won't really work very well, given how trivially easy it is to set up a new provider.

Answer 5

As far as I can tell, OpenID addresses only identification, not authorization. Stopping bots is a matter of authorization.

Answer 6

Notice that unlike conventional "per site" logins, OpenID gives you an identity that potentially transcends individual sites. Better yet, this identity is even a URI so its perfect for using with RDF to exchange or query arbitrary metadata about the identity.

You can do a few things with an OpenID that you can't do with a conventional username from a new user.

Firstly you can do some simple whitelist operations. If *.bigcorp.example are OpenIDs from Big Corp employees and you know Big Corp aren't spammers, then you can whitelist those OpenIDs. This ought to work well for sites that are semi-closed, maybe it's a social site for current and past employees.

Better though, you can make inferences from the other places that specific OpenID has been used. Suppose you have a map of OpenIDs to reputation values from Stackoverflow.com. When someone shows up at your web forum with an OpenID, you can see if they have decent reputation at Stackoverflow and skip the CAPTCHA or probationary period for those users.