Google is shutting down OpenID 2.0
developers.google.com
developers.google.com
> If you use 'Login with X' you're giving X access to all your accounts.
That's definitely not correct. You are giving X to access only whatever scopes you allowed, on a single account.
Here's an example of just 'userinfo'. Click this and see what it asks for: https://accounts.google.com/AccountChooser?service=lso&conti...
Per the screen, it only allows:
" - View your full name, profile picture and profile URL"
" - View any publicly available information on your Google+ profile (if you have one or create one in the future)"
It can't see your photos, see your contacts, read your email, post G+ messages, or anything else you didn't authorise.
So, in other words:
- RandomWebApp lets users log in with Google.
- A RandomWebApp user has a Google account, and allows RandomWebApp to oauth against his Google account.
- Since Google issue the access token used for RandomWebApp, Google could conceivably access RandomWebApp on the user's behalf.
That's a legitimate concern.
I don't see how separating identification and authorization conceptually helps. You have to trust your identification provider, in any kind of a federated or multi-party system. (Ie, a system where you can log into your google account and get access to another system, whether using OpenID 1.0, 2.0, OAuth, whatever).
Having Google hurt me is what I fear.
Google's use of its identity service is not on an equal footing as RandomWebApp's. Having a Google+ identity means accepting its TOS for a specific list of services provided by Google[1].
Violating the TOS (eg, by misusing, even accidentally, one of Google's services (think DMCA and ContentID mis-tagging fair use material, or even by not providing the name that the US has registered for you)) means losing your identity. That has definitely happened to at least a dozen of people I know.
Additionally, Google enforces identity in the context of a company based in the US. Whatever obligations it has in front of its government, and whatever weaknesses the government finds, will allow misusing your identity, even when Google itself isn't being evil.
[1] Excerpt from the TOS:
> Our Services are very diverse, so sometimes additional terms or product requirements (including age requirements) may apply. Additional terms will be available with the relevant Services, and those additional terms become part of your agreement with us if you use those Services.
Being authorized to use a particular account is still seperate from proving who I am. I have visions of going to the Pentagon and I say "Hi, President Obama here, give me access to all your intelligence data" and the analysts saying "Certainly sir! You have top authorisation, here is all the data". :-)
Actually, that would work better at a bank. "Hi, I'm Donald Trump, give me a million dollars from my loose change account, thanks!"
OAuth definitely does authenticate though (hence the name).
Your first sentence is totally correct though.
Hope that helps.
The conflation of authorization with authentication is an accident and a mistake. They are still quite separate concepts. Authentication is about verifying identity. Authorization is about privileges afforded a given identity. Access control models usually depend on some form of upstream authentication.
The third-party authorization flows provided by OAuth are not intended to establish or verify a user's identity. Their purpose is to extend a user's access to a third-party in a limited way without sharing passwords.
Social Sign-in is an accident of 3-Legged OAuth and its use for this purpose is considered a very weak form of authentication.
OpenID Connect takes the best ideas from preceding identity protocols and incorporates them into OAuth flows, giving the best of both worlds.
More information on all of the above here: https://github.com/christiansmith/anvil-connect/wiki/Referen...
Can anyone advocating OpenID connect give a single sentence explanation of why people (developers and users) would want to use it vs limited scope oauth?
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.
The odd thing is that I didn't even know it existed until this whole conversation about Google dropping OpenID came up...and I use Firefox as my browser across all my devices, I use sync, I use Thunderbird, I follow the Firefox OS development with interest, and yet, I had no idea Persona was a thing.
I've always been uncomfortable with Google and Facebook being my "identity" provider, and I've been equally uncomfortable with the fact that they would happily provide those authentication services but won't accept them (i.e. I can login to thousands of services using my Google or Facebook account, but I can't login to Google or Facebook with any other service account). I simply don't like Google and Facebook owning my online life, but the convenience of it often trumps the ethical and privacy implications. I have, thus far, avoided integrating Google or Facebook logins on my sites because of the ethical implications, but I hate making my users keep up with passwords and usernames.
Why aren't more websites supporting Persona?
For my part, I plan to integrate Persona into the next version of my company website launching early this year, as well as our wiki and blogs. I may even try to figure out how to fit it into our products, somehow.
I found the following, seemingly maintained, extensions for Persona support in the apps I use for the websites I maintain:
https://www.drupal.org/project/persona
https://github.com/tmarble/nongrata.
It was actually a snap to implement. I did most of the coding at it took me maybe a few hours total and I NO idea what I was doing at the time. So if you want to USE Persona or integrate with Mozilla's implementation, there's nothing stopping you.
Writing the full stack of a Persona implementation is a many week to several month job for a half a dozen member team not only for development but from an infosec point of view.
It allows all your users to log in to Persona-supporting sites with their @yourdomain.com address, bypassing the bridge, and supports various nifty features like catch-alls, two-factor auth, etc.
Push for it. Implement it anyway. Work on it and write to Mozilla giving your thoughts about it. Whenever authentication is mentioned on HN, write about Persona and why it's still relevant.
That's the best you and I can do. Best of luck, we'll need it...
Come up with a way to market it that makes sense to your mother in under 10 seconds. The "why the heck is this better than the Facebook button" is something Mozilla marketing couldn't crack, and until that gets solved you can't get the "who the heck is Bruce Schneier" crowd to switch.
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.
On the client side, there's a glut of OpenID Connect implementations for various languages, or you could outsource it to the likes of mod_auth_openidc for Apache, or a node.js proxy using Passport, or whatever you'd like.
Once a user is authenticated, which can be handled by the libraries just fine, the rest of the data model is simply OAuth2 and a key/value list of claims about the user. I'm not sure how anything is pushing smaller players out, so long as those players are willing to use MIT (or equivalent) licensed code?
1. https://github.com/orf/simple/blob/master/simple/app.py#L381
Depending on what you are working on, you can use it how it is right now. It's nicely integrated into gmail, it works good enough for other mail providers. There are modules for probably every big web programming language and for many frameworks, most blogsoftware should have a plugin for it.
I use it in all my personal projects and had no issue with persona itself. The one issue was that the sinatra gem is unmaintained, but there is a fork that works fine.
Logic being if someone controls your email account already, it doesn't matter that you have two-factor auth, they can shut it off because they control your account. A lot people using two factor auth with their Google account have been hacked exactly this way.
Can you explain this a little more? I don't think I understand, because to me it sounds like you're saying, "once your account is hacked, two factor authentication won't help because your account has been hacked, so the adversary can disable two factor authentication". Don't major changes to accounts like that sometimes require re-authenticating with all required factors? I need to do this if I want to add a bill pay recipient to my bank account even if I'm already logged in.
http://www.makeuseof.com/tag/two-factor-authentication-hacke...
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 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.
Another reason why I don't feel happy about forcing people to make passwords for random web sites: most people are really bad at understanding risky computer behavior. Do you have a parent or relative who uses the same password for everything? I do. Despite my best efforts to warn them, they are not convinced that this is a dangerous thing to do. I don't think they're alone in this. Education is not enough.
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!
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!
In future the button will change from "G"-Login to "G+"-Login. As somebody else stated, Google said, that a normal Google account will suffice in the future, but alone the wording and the new button will alienate people.
"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
https://developers.google.com/accounts/docs/OpenID#shutdown-...
and from common sense.
BTW: Maybe you should also read my full post, before answering.
Heh, I see that you edited it to add more since I originally pressed "Reply".
You imply Google is "evil" because they write "only about Google+ SignIn", but I'm not seeing that. The link that you provided has two sections, migrating to Google+ SignIn if you are already using a Sign In with Google button, and a section on how to migrate to just basic OpenID Connect. It doesn't seem hidden away like you are implying.
On the same page, they list how to migrate to OAuth 2.0/OpenID Connect, and even say "If your OpenID 2.0–based app does not need social features or is on a platform not supported by Google+ Sign-In, or if you want to work directly with the OAuth 2.0 REST APIs, then we recommend migrating to Google's OAuth 2.0 login (OpenID Connect) solution, as described below."
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.
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.
https://www.grc.com/sqrl/sqrl.htm
(I think the final spec will launch in a week or two.
See my post here https://news.ycombinator.com/item?id=8790768
Very inconsiderate.