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.
This gives me the creeps. Authorisation and identification are not the same. If you use 'Login with X' you're giving X access to all your accounts. That's not just third party attestation of your identity. It's kind of like saying a passport is what gives you access to your home country... in reality your status as a citizen is what gives you that right, the passport is merely a convenience.
I think you are misunderstanding what he is saying. If you use Google to prove your identity to every website you use, you are giving Google access to all of those websites.
I believe the intended meaning was that if you login at randomsite with google, google has access to your randomsite account, as opposed to randomsite having access to your google account.
It's a legitimate concern, but there's no way around it with third-party authentication. You always need to trust your identity provider, don't you?
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 impersonate me is not what I fear, it is so obviously evil.
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.
That's not a very quiet way of doing it, though. Even if they hid the reset email from me, I'd be locked out of my account, which could raise suspicions.
Authorization of a null permission is effectively the same as authentication, though. I think the GP's point was that authz implies authn, even if the set of permissioned authz'd for is empty.
I'm a tad confused... To be authorised is great, but authentication must first happen surely? Authorisation says I can access x, but authentication says I am who I say I am!
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!"
Technically you don't authenticate using OAuth, you just have a secret token - which is proof you own the account. If you wanted to stretch your analogy, you could say a check from Donald Trump is just an authorisation.
OAuth definitely does authenticate though (hence the name).
Great question. Think of it as "Hi, I'm an individual who has an oauth access token for President Obama's userinfo.me scope. The only person who can authorise this is President Obama".
Even though its community maintained these days, Mozilla Persona was a great authentication mechanism with federation support. I loved using it. A pity it failed to get traction.
In fact, unlike previous OpenID protocols, OpenID Connect is a profile of OAuth 2.0.
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.
You've said limited scope authorisation is weak authentication, but you haven't said why in your post.
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?
That was actually understood a decade ago as well and was part of the conversation that led to OpenID and OAuth. It was suggested close to a decade ago that they both merge efforts and they have both struggled to find their place. Development on this scale just lags a bit behind, specially when the community around it is so fragmented and opinionated.
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.
So, how to do we revive Persona? I mean, it's still around, but it's been kind of back-burnered by Mozilla.
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:
I wrote an Mozilla Persona integration in Clojure with Tom Marble (of the OpenJDK evangelist fame at Sun) and friends at the Clojure.MN meetup a few years ago, here:
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.
On the provider site of the equation, I wrote an "identity provider as a service" app that you can just drop in to your existing domain by adding a single file:
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.
> So, how to do we revive Persona? I mean, it's still around, but it's been kind of back-burnered by Mozilla.
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...
> So, how to do we revive Persona? I mean, it's still around, but it's been kind of back-burnered by Mozilla.
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.
When I see such a proliferation (I looked at one architecture image of OpenID.connect and was shocked) than I am reminded of SOAP and I again think, that one reason might be, to hold smaller players at bay -- and to give the bigger players an advantage. For Facebook, Amazon or an other big internet company, it is really easy to even implement a big stack of software with complicated architectures and many features -- but for a four people start-up it is a big problem.
Honestly, if you already have a working OAuth2 server implementation, adding OpenID Connect support to it is not difficult. For oauth2-server-php, the OpenID Connect extension is a few hundred lines.
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?
I added persona login to Simple (a Python blog I maintain). It was super simple and painless[1], much better than the basic-auth I was using before. This makes me wonder why nobody is using it - is it a marketing issue?
Persona is/was great. It's hard to get a grassroots/delegated identity service off the ground when everyone has a Facebook/Google account (and doesn't understand the privacy tradeoff). The lack of support for delegation (the original use case for OAuth) was also a problem.
I don't believe Mozilla gave it a good go, though. Hell, we didn't even get native Firefox support for it, which was planned from the beginning. They just sort of gave up on it.
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.
You should. Not necessarily you, but a lot of startups are on here and they all should be pushing persona logins. It works, its available, go get it If enough sites adopt it it puts pressure on both Google and Mozilla to implement it as a browser feature the way it was designed to be. Then we have personal logins without information jacking or the potential for tolls on logins.
Persona ameliorates the need for two-factor auth because you have to have control over an email account registered as the provider for Persona to interact with the user.
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.
> 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.
Social engineering is the most common cause of account hijacking with two-factor. Check this out: they used his cell phone provider to get at his google account.
Persona does not require any interaction with Mozilla. If your identity provider wishes to require 2FA on Persona logins, he may do so. Persona is a protocol for signing identity assertions. Authentication is out of scope and thus not defined.
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.
I think there are a lot of users who feel the other way around, they can't trust "some random website" with their facebook / G+ identity. They would rather just make a throw away account with some easy to remember password.
I would agree that this is a major flaw, if the "scope" were unrestricted. But most of these systems support a capability-style model where you can say: "I give you permission to let me log in as myself, for this particular web site. But you have no other authority to do anything else as me." For example, "email" scope: https://developers.google.com/+/api/oauth#email, or the Permissions in Facebook login: https://developers.facebook.com/docs/facebook-login/permissi...
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!
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.
That is right. But till now, I could use a simple Google acount (not G+) to login for example at Stackoverflow.com.
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 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.
> 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.
Where does it talk only about Google+ Sign-in as the migration from OpenID 2.0?
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."
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.
[1] http://openid.net/connect/