Authentication

I come from a corporate world of internal application development where the concept of a single, unified, user identification is handled through the official company email and corresponding backend password validation system. So when I create an application, there’s no question or issue about how and what identity provisioning mechanism to use. The corporate email and password ruled everything.

But the real world is a different beast.

Reality

Out here, the use of a user email implies the need to register it, and therefore to create a unique password to associate with it, and I, as the application developer, now have to store that password. It would be great if everyone picked a unique password for each site so that if there is a breach and the password becomes known, all that has to be done is to nuke that password and no one can get into the site. However, that’s not how people work. Passwords get reused… a lot. One password to rule them all is all too common. Combine that with a known email, and that of course spells trouble.

But there are certainly ways to actually store passwords securely. You can hash and salt them to obfuscate the actual password and only care about what the password represents. There are also numerous services out there that allow you to leverage them in order to validate a user. You can do things like log in via Facebook, Google+, Twitter and even Mozilla’s Persona initiative.

All of these put the validation, verification and identity check of the user on other systems so that you can leverage their user validation infrastructure and just validate who is accessing your site without becoming the actual provisioner of the security credentials. As a developer, less is more in this case. Doing this completely removes the onus of password security storage back to the “other guys” and it’s one less thing to worry about. All I need to worry about is who the user is and keep track of that information in my locally.

Now, are there problems this sort offloading entail? Sure. Your potential users need to be a member of one of the services that you’re coding against (though something like Persona is trying to eliminate that as much as possible). It’s also hard to correlate one person’s fecebook account with their google+ account unless you get something definitive to connect them together (like the underlying email address or an explicit login to associate one with another). This may happen intentionally by people to create a new account, though that’s something already present with email based logins anyway so not much of a new issue. It should actually be less of an issue since you can hope it isn’t as easy to create duplicate accounts on these other system (but that would be a naive assumption).

What’s actually worse though is the unintentional aspect duplication: poor memory. Many a times I’ve forgotten if I’ve signed into a site via facebook, twitter, google+ or something else. So the developer will need to take that into account as well.

But despite that, I think removing the onus of password storage and security is a good thing. You know, just in case, not that anyone would want to breach a site I create :).

In the end, it’s more about simplicity. I just don’t want to hassle with it. The less I deal with sensitive material, the less likely it can be breached.

New Project

Hence this project: Authentication Module

The goal is to create an easily usable Java servlet base module that can be leveraged as the login mechanism for anyone developing a site. Well, for the time being, that anyone is me, and I just didn’t want to rewrite this part for each site I wanted to create. I’ll have a little more inner details about the project in the future, but for now, you should be able to run it via a git clone and a maven call.

The purpose of this module is to provide the developer with all the necessary code and routine to allow for the end user to log in via the provided 3rd party services and return back the identifying information for the user so that their information can then be stored in the application as the local user. No more having to deal with passwords, just a return of the critical information about the user the system needs to allow a customized experience.

What the developer does with that information is beyond the scope of this module (I’m planning on creating a new module for that), but this will be a good jumping off point to just get going quickly.

I hope it’ll be useful to people. You can check it out on GitHub and feel free to suggest any requests, fork or pull or spoon or whatever you like with it.

security and “doing things right” are always such tough issues. personally, it’s a thorn in my side, hence the need to modularlize and just make it easy and reusable