I am about to implement this on a website and wonder if I have missed the point somewhere. The website is a private sports club and we don't want just anyone logging in - they have to be paid up members. However Open Id might make it all simpler for the member.
I've built a test using 'Openid.php' and it all seems to work, but I'm wondering about linking that to the real club account. How does it know that the persion logging in via - say - Google, is really the member?
I noticed that when I started using Open Id on Stack Overflow, it just worked, I never had to verify / confirm anything and having created the SO account, I could just log in using Google. Nothing asked me to verify that the person logging in via Google really was the same person (me) who created the SO account. I assume it probably did this by comparing email addresses, figuring that as they matched we were the same person, then storing the Open Id Google identity.
However, it seems to me therefore that if I use that approach, if a rogue knows the email address of a club member, all s/he needs to do with some Open Id provider is to change their email temporarily to be that of the club member, go to the club login page, use the relevant Open Id button, it'll all match up and they'll be in. Email addresses aren't private, so not secure.
It seems to me therefore that to make this reasonably secure, I need a mechanism whereby the member logs in (at least once) using his or her true club login / password, then has a method of validating and saving the Open Id response identity, effectively saying "yes, this is really me".
Less convenient, but more secure. Am I right?
The point of OpenID is that the OpenID provider (e.g. Google) takes care of the login details like passwords and possible two factor authentication and such. Your server just gets a thumbs up with a "we have positively identified that this is user XYZ". You are then free to do with this information whatever you desire. Whenever Google tells you "this is user XYZ", you can be sure it's the user that Google knows as "XYZ". That's a unique identity which nobody can fake; the OpenID protocol itself takes care that this transaction is secure and cannot be spoofed.
It of course means that the OpenID provider needs to be trustworthy and secure too, but this is up to you trusting it. On your end you create an account for that user and link it with the OpenID credentials which is Provider + ID, not just the email address itself. If another user logs in through a different provider but the same email address, it's up to you what to do. If you don't care about the email in your own service, there's no problem. If you do use the email as identifier in your service, you need some confirmation feedback loop to ensure nobody can hijack another user's account.