We are developing a web system and considering using the Open Id feature. Do you think it is any better than the usual way of loggin users in? If we use the Open Id feature that means the users will be redirected to the site of their choice of Open Id providers which would take more actions. Then they have to login there and get redirected back to our site. Would users be comfortable with this?

Note: It's more of a social networking site but not anything bulky.

  • 3
    This is completely subjective.
    – Bill Weiss
    Jun 18, 2009 at 23:12
  • The answers here are not generally applicable for building Enterprise Apps, where businesses already have their own directory. In those cases you should consider federating your own Directory using WS-Trust or via the Open ID protocol Aug 19, 2011 at 19:39

24 Answers 24


I love OpenID, and it's absolutely better than the "traditional" per-site credentials metaphor. I don't want more credentials to manage, and I don't want to trust J. Random site to store credentials I provide securely. I think that users will become more comfortable with it as it becomes more commonplace. Hopefully it becomes more commonplace.

  • 2
    It is not what? Commonplace? I don't seen a lot of sites using it, but I hope more will. I hope it does become commonplace and well accepted by users. Right now, I don't have a sense as to whether the average end-user "trsuts" OpenID or not. I get the feeling that the vast majority don't care at all and will click thru anything to get at what they're trying to see... Jun 10, 2009 at 15:52
  • 3
    I'd say the problem is not trust, but rather that the "average" end-user has most likely never even heard of OpenID..
    – dbr
    Jun 15, 2009 at 15:41
  • 2
    I think "trust" is the solution. To "sell" OpenID to users we need to be actively telling them "We're letting Google / Yahoo / etc handle authenticating you and not storing your username / password on our servers..." It's a positive think-- take away and techncial jargon and just relate it as the good thing that it is. Jun 16, 2009 at 2:40
  • That depends if you think relying on google / yahoo / microsoft for your authentication is a good thing. If your app can't be trusted to handle my authentication, why in the world would I let you handle my data?
    – Jim B
    Jun 18, 2009 at 16:23
  • 1
    @Jim B: I trust the J. Random app manufacturer to do good enough job storing my data (and if I don't, I'll store copies of it myself). Authentication is a harder problem, IMO, and I'd rather have the "big guys" do that. Having said that, I don't know that OpenID is appropriate for every type of application. For logons to "casual" sites, like Server Fault, forum sites, etc, I'm fine with it. If I'm transacting business, I'd be a harder sell on OpenID. Jun 18, 2009 at 16:56

Don't forget that it doesn't have to be an either/or option. You can (and probably should) add OpenID support in addition to traditional login methods. This won't scare away 'general' users - they just use the existing method, while making life much more pleasant for those who use OpenID.


OpenID provides a number of advantages, chief among them allowing you to get lazy with authentication. Authorization is still your problem, but at least you don't have to be as concerned about securely storing credentials. This is a good thing in my opinion. The 'net need more 'relying parties' like serverfault.


If you login with an OpenID, you only need to login to your provider once - the second time, user won't even see the provider's page.

Also, maybe RPXnow will be interesting.


I personally have crossed the line over to loving OpenID. I used to be resistant to it from general paranoia. Now it's just too much of a pain in the a$$ to keep everything straight. I do agree that non-tech users might struggle at first, but I think the more wide-spread it becomes the more comfortable people will get. Some sites offer both a traditional (local) authentication system and also the option of using OpenID. I think that education is going to help a lot here, so if you clearly explain what OpenID is and its benefits then that will go a long way towards acceptance.

As a Single Sign On (SSO) technology it is open to the general risks of any SSO. From that perspective I'm not yet ready to integrate my bank or medical sites into it :) Not that it's offered by them anyway...


I'll throw in that with OpenID you usually want OAuth which gets criminally low press.

Others have elaborated enough about OpenID, OAuth adds to the set that another site not only knows who you are thru your OpenID provider but you can also tell what the site in question is allowed to know about you.

  • needs email for user details
  • needs first-/lastname for user details
  • needs country

may be all fine. How about those:

  • social security number
  • credit card number
  • telephone number
  • postal address

So OpenID + OAuth is a great combination, by using both you not only have a single place to keep a username and password but also where you keep details about yourself and don't lose overview about which site has access to what details about you.

  • I love OAuth in theory. In practice I've found very little granularity. Most OAuth consumers seem to be asking to be able to access (read and write) all your data.
    – Evan
    Jun 16, 2009 at 7:40
  • The data you're talking about -- email, name, country, address, etc -- can be transferred with an OpenID extension like Simple Registration (sreg) or Attribute Exchange. The limitation is that it can only be transferred at login time through the user-agent. The thing that OAuth adds is the ability for the client application and the server to have a direct connection over which the client can make API calls without the user present, which may be more useful for some cases. (e.g. you want the email address when you send the newsletter, not when the user logs in.)
    – keturn
    Aug 14, 2009 at 19:17

I can think about a scenario when OpenID will gain many users on the spot. Suppose a major site loses millions of user passwords to evil hackers [*], and the list leaks out. Most users will be in panic, not only because of the one specific account, but because they use the same login/password for multiple sites. And they do. I know, I do. And I do not keep any track of these accounts, so the result is that I can never change my passwords.

Now when I know that a villain can steal my accounts what will I do? I'll try to get through this overwhelming task of changing passwords. Or I'll stumble upon OpenID concept and try to convert all these accounts on the occasion. This would mean I effectively still have a single login/password for multiple sites, but now I can at least easily change the password in all of them. And in case evil hackers steal my OpenID I have a single problem to request password reset or at least to disable the account.

[*] - read: script kiddies


The more i visit various web-sites, the more i want a single sign-on feature.

Every web-site thinks theirs in the most important. Every web-site insists that you create an account before you can do anything. StackOverflow, Serverfault, Wikipedia, WowWiki, Wowhead, MS Forums, CodeProject, CodePlex, on and on, ...

They all demand i create select a unique username, a password, and fork over my e-mail address. Then they insist that i go check my e-mail before they let me post, edit, download, click, comment, rate, etc. There is no reason to not let me use your site the instant i wander into it.

i just want them all to shut up. i want a single login that i can just use everywhere, with an e-mail address that is a black-hole so i never have to read their garbage.

OpenID seems to be that. But it was only possible once Google supported it. Before that, it was StackOverflow's own propritary login system - that they were too lazy to host themselves. Now that Google supports OpenID, it's actually conceivable that everyone will already have it.

These days, i loath having to create accounts on web-sites, and curse the operators who think i should have to create an account first.

Don't make me loathe your site, too.

  • Umm... stackoverfow/serverfault don't require anything to post. Try it: use a different browser or machine and visit serverfault, and you'll be able to ask or answer questions without signing up. If you keep using that same browser, you'll even earn rep and privileges over time, without ever giving them anything.
    – Joel Coel
    Jun 18, 2009 at 13:37
  • and it wasn't proprietary to stackoverflow... Yahoo, Facebook, and myriad others all support and encourage it :)
    – warren
    Sep 25, 2009 at 5:59
  • The great thing about OpenID standards is that there's so many to choose from!
    – Ian Boyd
    Sep 25, 2009 at 16:46

There are benefits of using openId on both sides : 1. Developers don't need to implement the login system (database, client processing, app security etc.) 2. Users don't need to remember an extra set of credentials.

On the onther hand you might scare some of the users that aren't really computer savy and will be reluctant to give away say thetir google credentials to login to your site.

The best solution would be a hibrid system allowing for both OpenID and on-site registration but this would really ruin the first benefit I mentioned.

  • hmm, everyone I know was happy to give facebook their full u/p for it to download their addressbook to spam me 50 times... Jun 16, 2009 at 20:28

The other thing OpenID gives your users is the ability to use stronger credentials. I see some concern about phishing in the responses here, but you can pick an OpenID provider that doesn't use phishable/replayable credentials at all. SSL certificates or Information Cards, for example, are supported on some providers. myOpenID has a thing where it requires you to answer a phone call before you can log in. I'm pretty sure there are other sites that use hardware tokens.

Yes, most of your users will probably just click the Yahoo button and not use that. But it gives them the choice, and you don't have to worry about the implementation details. I claim it's easier to add OpenID support to your site than it is to support SSL certs in a cross-browser way. And it's certainly easier than supporting all of SSL certs, Information Cards, phone verification, token verification, DDRpass, random dot stereogram auth, or whatever wacky thing they think of next.


I'm not trying to change anybody's mind. Please, consider these facts. OpenID is only two things different from user+password authentication system:

  • place where your authentication happens. If you used name+password before, OpenID changes place where the password is checked. If you used certificate before, OpenID changes where certificate is checked.
  • OpenID URL is unique to the whole WWW (not considering alternative root DNS-es)

What i'm trying to point, is that nothing more is changed:

  • OpenID is not a replacement for registration procedure (but it may simplify registration via sREG extension)
  • it is not less secure. If one used short passwords before, he will use them again.
  • it doesn't imply that you can not have hundreds of different ids for every website out there for paranoid people.
  • it doesn't imply "OMG that's geek technology, run away!!". No, you can make nice shiny buttons like StackOverflow group of sites did for common OpenID providers. That's a lot more user friendly.
  • it doesn't imply redirects. You can make authentication in iframe or separate browser window.

That's like with any other technology. Most of the things people talk about it is myth because they didn't take a time to study it or because they used wrong implementation.


OpenID is more complicated, and makes you dependent on the other providers not going down.

One of the problems StackOverflow has with it, is that if you sign in with a different OpenId than the usual one you use, you lose your ratings and badges (maybe they've fixed that by now, haven't heard). There was one time I couldn't sign in for an hour because my provider was down.

  • OpenID does provide a way to get around that - you can use a personal website to delegate to your real OpenID provider, so if the provider goes down, it's easy to switch to another one. Of course, that's probably not the kind of thing most non-techies are up to doing...
    – David Z
    Jun 15, 2009 at 13:53
  • 1
    It's not "complicated", it's just different. With OpenID: "enter openid.example.com, click Okay, enter your password and you're signed up". With the current system: "enter your username and password and possibly other details, check your email, click the link to activate your account, finally re-enter your login/password". Day to day OpenID use is absurdly simple, and basically the same - enter your OpenID, click okay, enter your password.
    – dbr
    Jun 15, 2009 at 15:47
  • 1
    Also.. "that if you sign in with a different OpenId than the usual one you use, you lose your ratings and badges" - err, if you sign in with a different account, of course you lose your account details.. stackoverflow/serverfault allow you to use multiple OpenID accounts, and OpenID allows you to use your own personal site as an OpenID provider, or as a "proxy" for one or more (well, a delegate), as David mentioned
    – dbr
    Jun 15, 2009 at 15:49
  • 2
    "OpenID does provide a way to get around that - you can use a personal website to delegate to your real OpenID provider, so if the provider goes down, it's easy to switch to another one" I've found that to not really be the case. Most OpenID "consumers" I've dealt with store the redirected (or canonical) OpenID URL, not the one that was delegating.
    – Evan
    Jun 16, 2009 at 7:35
  • 1
    (Just checked, and that includes StackOverflow.) A lot of OpenID consumers allow you to attach more than one ID to the same account, which I can see being useful.
    – Evan
    Jun 16, 2009 at 7:37

I hate openID and it was the main reason to NOT signup at serverfault/stackoverflow What about user privacy? Some users, like me, are extremely paranoid, and does not like to mix facebook/yahoo/google information between various websites

  • 2
    -1 OpenID does not share information between the websites that use it.
    – David Z
    Jun 15, 2009 at 13:55
  • 1
    i know, but i don't give my email to anyone. I use disposable mail everywhere, and if a website blocks disposable mails, well, they won't get my membership. Using openid = using my real mail = i hate so much Jun 15, 2009 at 15:12
  • 1
    Don't forget that, thanks to OpenID, even Jeff Atwood's account was hacked. codinghorror.com/blog/archives/001263.html Jun 15, 2009 at 15:19
  • 5
    Mag_Dude .. Atwood's SO account was hacked because he used the same password on an insecure site as he did on his Openid account. The guy cracked his password on the insecure site, then checked his openid account to see if it was the same, and it was.
    – tomjedrz
    Jun 16, 2009 at 18:20
  • 2
    @Magnetic_dud: OpenID client sites like StackOverflow/Serverfault can't steal your credentials with a fake login prompt. All they get is your OpenID name, but that's neither your username or password. The only place you every enter your username/password is with your original chosen OpenID provider. The only risk here is that your original OpenID provider will be hacked or go rogue, and I'd rather trust someone for whom keeping credentials is core-competency to do it right than a bevy of random web sites, and one of whom could make a mistake.
    – Joel Coel
    Jun 18, 2009 at 13:35

OpenID while nice conceptually faces IMO an uphill battle because it's a) hard for developers to implement and b) hard for users to get used to the concept of using a url. The username/password usage pattern is pretty tightly ingrained at this point.

That said, have a look at Clickpass (www.clickpass.com). They are actively trying to make OpenID easier to use.

Good luck.

  • I like the fact that serverfault provides big, clickable icons for the most common that does all the work for you! Jun 16, 2009 at 20:31

Not yet.

It needs browser support. Browsers would complete an excellent user experience with OpenID, as they could manage your identities in a centralized fashion and make things very simple (it seems that the website you are visiting is using OpenID, do you want to use http://yahoo.com/user to log in?) and secure.

But right now, you need a significant effort to make OpenID usable. As I see it, you either need to provide OpenID as an option or provide your own OpenID provider to your users (making them free to use a third party's service).


Think customers. Is your target customer a geek? If yes, OpenID will impress your customer and help your site. If not, the extra work in making it non-geek friendly is going to drain away resources from delivering content your customer cares about. Focus on delivering value to your customer first.


The problem with OpenID is that is great for things like ServerFault where the level of trust in someone's identity isn't really a consideration -- once you start caring, that's where life gets complicated.

It gets complicated, because when I control my authentication provider, I implicitly trust that provider because I run it, and presumably have implemented it to the standard that I require. When I move authentication outside of my control, I now have to assign a level of trust to the authentication provider as well.

At my employer, by law, I cannot trust ANY major OpenID provider out there because:

  • They do not enforce periodic password changes
  • They do not enforce password length/complexity
  • I cannot audit their systems management practices

That isn't a comprehensive list by any means.

To make OpenID work for non-trivial applications, I need a trusted provider -- and must limit my users to that trusted provider (or providers). That kind of defeats the whole "single username/password" advantage. Even then, I may still need to do some identity verification for users at higher trust levels. Seems like alot of work to me, especially when managing your own authentication provider isn't rocket science.

IMO, governments have the potential to make this technology work. If a state/provincial DMV or the post office offered a service where citizens establish online credentials, accessible via OpenID, you would be able to trust the Post Office/DMV credentials. (Because the government says: 'Thou shalt trust us') I believe that countries like Norway and Denmark are already issuing individual PKI credentials.

  • 2
    You know, you could build an OpenID provider that does all of those. Maybe charge for the service and market it to government employees as a secure, legal, single sign on that's compatible with the larger web.
    – Joel Coel
    Jun 18, 2009 at 13:40
  • That is a product that would rock, but it also sorta dampens the whole OpenID concept. Jun 18, 2009 at 20:36

For a social networking site, OpenID will help attract the tech savvy. However, if that's your only option it will scare away everyone else. Users are accustomed to signing up with new logins and passwords on each site. OpenID is new and foreign, and may make users wonder why they are giving their credentials to a third party. To a typical user, OpenID might as well say GiveMeYourInformationSoICanSpamYou ... it's just one more reason for them to doubt the integrity of your site.

In short - determine your user base, and either scratch OpenID or use both OpenID and an application-managed login system.


I wonder why people think openID is more secure. For tech savvy users, this might apply, but a common user would not spot the difference between a real openID login and a faked one that will scrape the password.
Even worse, they too will know which openID account to associate with this password, and can probably wreak much more damage than with a simple username/email/password combination.

openID is a technical solution for technical users, and not very helpful for ordinary users. So for technical sites it might florish, but I don't see that for ordinary sites any time soon.


I would say that yes, OpenID is better than the usual login solution from the user's point of view, for these reasons:

  • I don't have to remember yet another username and password for your site
  • I can use one login ID for multiple sites, if I want to
  • I always get the same username -- no adding numbers and random crap on the end of login IDs until I get one that's free
  • It will get more popular and better-understood by users as time goes on
  • Explaining to users how it works and the benefits to them is pretty straightforward
  • Most users will have a free email account from Yahoo or Google which they can use as an OpenID provider -> they probably don't even know this is possible.
  • Users can still give a different email address to the OpenID-provider one (if it's a free yahoo/gmail/whatever account) which you can have them click a link in to confirm, as a backup for sending "forgotten my password" emails or other notifications or marketing gumph to.

Remember that just because you have the option of OpenID it doesn't mean you can't also give users the back-up option of having a traditional username+password combo in case they don't want to use OpenID or don't have a provider. Nothing wrong with letting users pick which they want if they know, and otherwise defaulting to OpenID, imo :)


Open ID is one of those things you either love or loathe the idea of -- I think it really boils down to the idea of whether you view centralization of "authentity" enthusiastically or skeptically.

In other words, when you find out an account on an openid site is compromised, do you think, "oh sh!t, now I'm potentially compromised on every site I use that openid for," or "oh good, now I only have to change my password for all those sites in one place."


Working in this field we end up with lots of various login credential information. OpenID allows me to use an already established account to authenticate myself without having to setup yet another account and password. With many sites beginning to support OpenID there is much more of a choice in which OpenID authenticator you use to validate your identity.

You can also setup your own OpenID authenticator on your own site if you don't want to use one of the already existing ones out there. This way you can maintain more control over exactly what information is being given out when you are authenticated by it.

I think having the option to create an account or use OpenID to authenticate is a great combination that covers both the security paranoid and the ones that want the ease of use.


I think OpenID is great, and we are considering it for our site. However, we'd need oAuth, and we'd be wanting the email from users as well. We use that extensively, and one thing that we do is email a newsletter. We allow opt-out of that, but for our system to work, we'd want that.

It seems there is a hard core group of techies that hate to give up a user/pwd, and I can understand that. Some are privacy advocates, and I completely understand. Some are just lazy, don't want to set up a user/pwd, some are just takers. They want to get information from the Internet, but never pay for it in anyway, in any way (advertising, cost, etc.) I think that's a minority of people as most people understand they need to contribute back, or pay in some way.

You need to examine your site, what details/info you need, and then make a decision about if it meets your need. If it does, you can add it in addition to the current login method. Do you need to contact people, inform them of things, etc.

Having a central way to authenticate yourself is great, but there are issues, as mentioned, with a lack of password changes/complexity. However that's a user problem more than a site issue. A compromise takes place at the user level, which we will never solve. But it means that you, as a site owner, are not responsible if it occurs.


The only problem I see with OpenID is the following:

Imagine two affiliated sites. Both of them allow OpenID login. Surely then they can share the activity statistics between each other - say I do action X and action Y on the first site and then, when I visit the second site I get bombarded with targeted ads, according to my activities on the first site. For some reason the lack of isolation between the OpenID logins seems a bit unpleasant to me.

But the thing is, that the ultimate convenience of OpenID (one, hopefully secure, set of credentials) does not get eclipsed by the aforementioned downside. I use OpenID wherever I can, and was I to develop a web service for public use, I'd definitely make it support OpenID (perhaps with a conventional registration option).

  • If you use Google as your OpenID provider, they actually issue a different OpenID (which includes a big random string) to every site you visit, to prevent that sort of cross-site correlation problem you're talking about. Personally, I consider that an anti-feature to have by default, because it means if a site changes its login domain then all your Google-issued OpenIDs break, but it does address that problem. It'd be nice if it were optional.
    – keturn
    Aug 14, 2009 at 19:06

Not the answer you're looking for? Browse other questions tagged .