Tag: OpenID

  • forgot-passwordOpenID has many advantages. For the average user, the main one is not having to remember a thousand passwords. That’s obvious. But also consider not having to remember the username. Many web sites use the email address as username and that’s nice, but many don’t. And most people are not lucky enough to have a username that’s free everywhere. For my wife, remembering the username is sometimes as hard as remembering the password.

    Not having to worry about poorly programmed web sites leaking your password because they stored it in plain text and they have phpMyAdmin open without any password is also a big plus, but not something the average user would see.

    But for the developer, it has many, many advantages.

    Not having to decide on what identifier to use for your users (users vs emails vs ids). Not having to implement a log in screen, which means not having to worry about SSL encryption which means not having to get a dedicated IP address, a certificate, configure the web server accordingly and ensure that the site switches to https when it must.

    Not getting password for the user means you don’t have to store a password. You don’t have to figure out what is the appropriate encryption mechanism so that if your encrypted password leak, they are not readable. Not using plain text is not enough, as some encryption mechanisms are easily broken. Not having to worry about that is huge.

    You don’t have to create a signup page, people just log in. You don’t have to validate the password by asking for it twice or validate its strength or any other stuff like that.

    You don’t have to create a remember password page, which means one less place where you have to deal with sending emails. That’s always good. Also it means that you don’t need to store the email of the user. You may want to, but that’s your option.

    I’ve always been a fan of canned authentication and authorization systems. I’ve been using them since the days of PHP 4.0 and I used them in Django and ASP.NET (MVC). But with OpenID, it seems the authentication became almost trivial. Canned solutions were always troublesome because they had to work for everybody so they implemented a lot of stuff you don’t actually need and sometimes you spend more time fighting the bureaucracy of the system than producing something.

    Is it possible that without OpenID authentication and identity for the developer of a web site becomes something simple and trivial? Where rolling your own solution not only is simple enough, but also the way to go. I’m looking forward to my users being just in the user table, and not all over the place in users, profile, membership, etc. I’m giving the roll-your-own-with-OpenID a try. I hope to post positively about it soon.

  • When you create an ASP.NET MVC project it comes with a controller called AccountController that manages logging in, logging out, registering, changing password and so on. Since usernames and passwords are dead I converted it into OpenID and I’m just pasting it here for everybody to use.

    I’m using the DotNetOpenAuth library which you have to download, put in your project and refer. The difference between what I’m pasting and the example provided by DotNetOpenAuth is that I’m actually storing the user in the membership database, like the original AccountController.

    My work is based on the on the blog post Adding OpenID to your web site in conjunction with ASP.NET Membership. I really had to put a couple of hours on top of that, so I consider it worth it to post it. Scott Hanselman also provides useful information for integrating OpenID. I’m using the jQuery OpenID plug-in but I’m not going to post my views. They are really trivial and left as an exercise to the reader.

    I’m not using any extra tables, I’m storing the OpenID identifier (the URI) in the field for the username. This has the advantage of not requiring any other fields but the disadvantage that you can have only one identifier per user. There are some unfinished parts but since you are likely to customize them anyway, I don’t feel too guilty about not finishing yet. If you find a bug, please, let me know.

    (more…)

  • The future of OpenID, I believe, is more likely to be in hundreds… thousands of little web applications consuming OpenID because it comes built in with the framework used to build the application than the big guys consuming it:

  • After watching the OpenID community grow for years, I finally joined them. I’ve liked the idea from the first day I’ve read about it; aren’t we all tired, after all, of having to remember hundreds of usernames, passwords (sometimes with conflicting constraints: a password must have numbers, a password can’t have numbers)?

    From OpenID’s web site:

    OpenID means the elimination of multiple user names and passwords and a smoother, more secure, online experience. For businesses, this means a lower cost of password or account management, the opportunity for easier and higher numbers of new user registrations and the elimination of missed transactions because of user frustration with lost and forgotten passwords. OpenID allows for innovation in the authentication space beyond just using a password to “unlock” your OpenID identity, but the ability to strongly protect your OpenID and have that benefit move with you everywhere you go online.

    For me, joining the revolution was very easy. First I open an account on MyOpenID, then I installed the OpenID Delegate WordPress Plugin in my wordpress blog so my OpenID address is, actually, pupeno.com. So even thought I’m using a third party service, if they disappear I just pick another one (or become my own OpenID provider) and go on using the same address, pupeno.com. Isn’t it great? There are many other OpenID providers and many sites already supporting OpenID.