Practically, openID is being replaced by oauth. A decade ago authentication and authorisation were quite separate concepts. This has been replaced with a realisation that 'being authorised to use a particular account' (Google Account, Twitter, FB, etc) is sufficient to prove ownership of that account and therefore identity.
Mozilla Persona _should_ have been the successor to OpenID. It solves almost all of the problems with OpenID, which were:
1) The NASCAR problem. Arrive at a page for a site you signed up for with OpenID and be totes confused: which "openId" did I use for this site?
2) The privacy leak: If you used your Google OpenID, now Google knows that you logged into someotherplace.com with your "openid"
3) The ID problem. Wait, what? Yeah, like, how does someone keep track of which "openid" ID is "me".
The final problem is that not many people will write a full implementation of it other than the big players like mozilla itself or Google or Microsoft. And the latter two don't have a ton of incentive to do so.
I'm going to use this opportunity to transition my users off social loggins altogether.
I used Google and Facebook when first building the webapp because I simply didn't want to do the work of building an authentication system. It's lots of work to get right.
About a year ago I had a lot of users complain my site _only_ had social logins so I had to implement my own anyhow.
Now I have it, I don't see a lot of value in keeping the social logins around.
I just need to ask users to add a password to their account and they can login using email/password combo.
I don't know your audience, so perhaps this makes sense.
I don't want to remember or keep track of yet another password for a random web site. If the web site requires login and doesn't support Facebook/Twitter/G+ login, then I'll likely give up and avoid the page.
OpenID 2.0 screamed "embrace, extend, and extinguish" loud and clear. It's 8 years later, probably not as evil (TM) as I had prophesied (more likely attributable to the death of OpenID rather than malice), but, yeah...
EDIT: Yes, 6, not 8. I got the 8 from 2008 stuck in my head, apparently. Oops!
What me frightens a little with this move (OK, I acknowledge that OpenID2.0 is deprecated and should be updated to something new), is that Google talks only about "Google+ Signin". And OK, as I read in previous discussion, Google will also in the future support logins from people with normal eMail account.
Still, I am worried, since Google does not clearly communicate these facts, but when you look at their communications, you read only about "Google+ Signin" and you have to search to find that you do not need Google+ but just the new protocol OpenID connect.
I don't like to see such communications from a company, that once claimed (long, long time ago!! Do you remember Google?) "Don't be evil".
It is OK, when they move away from an old protocol, but it is not OK, when they (and it very much looks that way to me!) use it as vehicle to market their products. Google has troubled people enough with forcing G+ on them -- so I even find it more troublesome, how they do it now (as it seems to me currently).
I fear, Google is still hunting after Facebook and is by the way inheriting its bad habits.
As I see now, they also want that a new button is used -- something with G+ on it. I see, they really lay the pressure on the people -- many people will think, that they need a Google+ account to use this feature (even if not required). I would say, Google you are going to hurt yourself!
I myself, was thinking about using a "Login with Google" button in my application ... but now, with things changed, I will think twice, before I do such a move!
Google have never properly supported federated login. You should be able to login to Google services with an external account and not need to sign up with Google at all. Their Authentication and Authorization APIs have always been about pushing Google Services.
Google+ Sign-In is an implementation of OpenID Connect, with some nice features built on top:
"Google+ Sign-In is built on the OAuth 2.0 and OpenID Connect protocols. It supports over-the-air installs, social features, and a sign-in widget on top of standardized OpenID Connect sign-in flows. Google+ Sign-In works for all users with a Google account, whether or not they have upgraded to Google+." [0]
I don't understand where all your other conclusions came from.
Google's documentation is so confusing. I just wanted a simple tutorial which would tell how to get the name and email address of the person with the new API. That is all I need.
But the name Google+ Signin implies that this is related to Google Plus which I did not want. So I thought I have to use some other API for my simple needs, after wasting lot of time I realised I have to use Google+ login even for my simple needs. Couple of head banging sessions later, I realized this is just a vehicle to market their product.
There's no mention in here about the Python Users API that Google provides for managing users in your Python AppEngine application. Google hasn't updated the Python Users page (other than mentioning there are changes coming) and haven't indicated if they will or will not update the Users API methods to support the new auth methods.
Given I chose AppEngine in part because of the Users API, it would be nice if there was some clarification by Google on what they plan to do with the Users call and how provide some suggestions (or, heaven forbid, sample code) to show us how to do it ourselves.
Just a small update, because there's basically nowhere else anyone is going to read this given Google suspended Google groups for AppEngine and doesn't answer StackOverflow questions. I tried using the sample code from the User API pages and built this: http://kordtester2.appspot.com/. The app is using standard Google authentication, not the federated auth. The docs say it should work, but it's clearly broken.
Actually, it's considerate. Given the choice of having all of your users suddenly shut off, or a small portion of them, the latter is better. Suppose that the number is 1% of people that get shown this page. This means only 1% of the people are going to email you to remind you to fix it, instead of everyone at once. By gradually ramping this number up, you get the most notification with the least number of users inconvenienced.
[+] [-] teh|11 years ago|reply
[1] http://openid.net/connect/
[+] [-] nailer|11 years ago|reply
[+] [-] StavrosK|11 years ago|reply
[+] [-] nickbauman|11 years ago|reply
1) The NASCAR problem. Arrive at a page for a site you signed up for with OpenID and be totes confused: which "openId" did I use for this site?
2) The privacy leak: If you used your Google OpenID, now Google knows that you logged into someotherplace.com with your "openid"
3) The ID problem. Wait, what? Yeah, like, how does someone keep track of which "openid" ID is "me".
The final problem is that not many people will write a full implementation of it other than the big players like mozilla itself or Google or Microsoft. And the latter two don't have a ton of incentive to do so.
[+] [-] ldng|11 years ago|reply
[+] [-] brunoqc|11 years ago|reply
[+] [-] seanieb|11 years ago|reply
[+] [-] fintler|11 years ago|reply
[+] [-] jay_kyburz|11 years ago|reply
I used Google and Facebook when first building the webapp because I simply didn't want to do the work of building an authentication system. It's lots of work to get right.
About a year ago I had a lot of users complain my site _only_ had social logins so I had to implement my own anyhow.
Now I have it, I don't see a lot of value in keeping the social logins around.
I just need to ask users to add a password to their account and they can login using email/password combo.
[+] [-] dyoo1979|11 years ago|reply
I don't want to remember or keep track of yet another password for a random web site. If the web site requires login and doesn't support Facebook/Twitter/G+ login, then I'll likely give up and avoid the page.
[+] [-] ComputerGuru|11 years ago|reply
OpenID 2.0 screamed "embrace, extend, and extinguish" loud and clear. It's 8 years later, probably not as evil (TM) as I had prophesied (more likely attributable to the death of OpenID rather than malice), but, yeah...
EDIT: Yes, 6, not 8. I got the 8 from 2008 stuck in my head, apparently. Oops!
[+] [-] taytus|11 years ago|reply
[+] [-] PythonicAlpha|11 years ago|reply
Still, I am worried, since Google does not clearly communicate these facts, but when you look at their communications, you read only about "Google+ Signin" and you have to search to find that you do not need Google+ but just the new protocol OpenID connect.
I don't like to see such communications from a company, that once claimed (long, long time ago!! Do you remember Google?) "Don't be evil".
It is OK, when they move away from an old protocol, but it is not OK, when they (and it very much looks that way to me!) use it as vehicle to market their products. Google has troubled people enough with forcing G+ on them -- so I even find it more troublesome, how they do it now (as it seems to me currently).
I fear, Google is still hunting after Facebook and is by the way inheriting its bad habits.
As I see now, they also want that a new button is used -- something with G+ on it. I see, they really lay the pressure on the people -- many people will think, that they need a Google+ account to use this feature (even if not required). I would say, Google you are going to hurt yourself!
I myself, was thinking about using a "Login with Google" button in my application ... but now, with things changed, I will think twice, before I do such a move!
[+] [-] 7952|11 years ago|reply
[+] [-] timothya|11 years ago|reply
"Google+ Sign-In is built on the OAuth 2.0 and OpenID Connect protocols. It supports over-the-air installs, social features, and a sign-in widget on top of standardized OpenID Connect sign-in flows. Google+ Sign-In works for all users with a Google account, whether or not they have upgraded to Google+." [0]
I don't understand where all your other conclusions came from.
[0]: https://developers.google.com/accounts/docs/OAuth2LoginV1
[+] [-] sumedh|11 years ago|reply
But the name Google+ Signin implies that this is related to Google Plus which I did not want. So I thought I have to use some other API for my simple needs, after wasting lot of time I realised I have to use Google+ login even for my simple needs. Couple of head banging sessions later, I realized this is just a vehicle to market their product.
[+] [-] kordless|11 years ago|reply
Given I chose AppEngine in part because of the Users API, it would be nice if there was some clarification by Google on what they plan to do with the Users call and how provide some suggestions (or, heaven forbid, sample code) to show us how to do it ourselves.
[+] [-] kordless|11 years ago|reply
[+] [-] higherpurpose|11 years ago|reply
https://www.grc.com/sqrl/sqrl.htm
(I think the final spec will launch in a week or two.
[+] [-] nly|11 years ago|reply
See my post here https://news.ycombinator.com/item?id=8790768
[+] [-] knocte|11 years ago|reply
[+] [-] lowlevel|11 years ago|reply
[+] [-] mahouse|11 years ago|reply
Very inconsiderate.
[+] [-] fryguy|11 years ago|reply