How many sites do you visit regularly? How many times do you repeat the process of inputting username and password? Are you a regular visitor of “Forget your password?” link or you vehemently deny, saying you always remember all your passwords because they are all the same or follow the same pattern?

I Can Not Remember Passwords

You might say, “Are you kidding me, or you’re plainly a moron?” Yes, I probably am. During my early ages with internet, services offered were not that many and diverse like todays. I mainly used internet to check my email, hence remembering password was not a problem because I apparently used single password (or two for my other account).

Internet evolves, applications are built. New sites emerge everyday. I read news and article about new technology especially on websites and web apps. Another Joe said site A was cool because it offered yada-yada service. I dropped a visit, took a demo, and was eager to use the service offered. But it’s not free even it’s free (or it’s free with limitation if money is the term), i should be authenticated and authorized to use the service, hence registration (+payment) and another username-password pair.

After years, I found out that I had collected hundreds of username-password pairs. Hundreds? Yes, for sure. Credentials for e-payment should be different with the ones used in forums, emails, or other less critical service. Unfortunately,remembering which pair to be used in a site was and is always PITA. After being a regular patient of “Forget your password?”, I decided to organize login credentials so that I would never forget and could easily find out the username/password for a website/service. How?

Being a developer and part time information security lecturer, I’m familiar with encrpytion-decryption methodology. I created a text file which stored all my login credentials and then encrypt it with a chain of encryption algorithms. If I forgot one of my login credentials, I should only supply a phrase which acts as master password, the software does the decryption process and all login credentials are now exposed.

Nice, isn’t it? Yes, perhaps. It does solve problem with my absence in remembering passwords, but it doesn’t buy back 10 cal energy exerted for each username-and-password input process. This solution is also rather personal because not everybody can implement it. Technical knowledge is required and to know inside-out something technically is not everbody’s preference. A more generic and general approach is needed.

And it might be OpenID…

Single Login Mechanism Among Different Services

If you are yahoo or google user, you should be familiar with single login mechanism implemented on both sites. Now, let’s take Google as example. The diagram below describes Google account authentication process:

Google account authentication process

Google use centralized login for all their services. Once user has been authenticated in a Google service, he/she will be automatically authenticated and authorized upon accessing other Google services. No redundant username/password reinput is needed. This can be achieved because the web application checks user’s state while requesting a new service. If a client is already authenticated, access to service is given. The checking process can occur if small signature/info is stored at client side. In this case, cookies are stored at client’s PC.

With single login mechanism, authentication process now becomes easier. Now, user should only do authentication once to access all services offered. Less work and wrinkles. Yet, it’s not enough. Single login can only be valid for a single provider. Other providers may have their own single login mechanism. We still need more generic and general approach.

And OpenID could be the answer…

Passwordless Authentication With OpenID

OpenID is not a new term. It’s been around for a while. Let’s cite openid.net for its definition:

OpenID is an open, decentralized, free framework for user-centric digital identity.

Hmm… a bit vague definition. It deserves more explanation, nonetheless.

Let’s reminisce the classic method for form based authentication we usually find on websites:

Example of simplified network design for classical authentication

The picture above shows sample network for classical authentication. Client (name him John Doe) is browsing Site.com. A certain page contains private data which should be available only to registered users. A form which contains username and password (and probably CAPTCHA) is supplied to client. John will fill the form with him username and password. After submitting the form, the server will process the information. If a record is matched against the database, access is granted and private data can be accessed.

What makes OpenID authentication different? We’ll see another picture depicting sample network design for this type of authentication.

Example of simpliefied network design for OpenID authentication

Some new terms are introduced from the picture above:

• OpenID consumer :relying party, application or site which authenticates user with OpenID
• OpenID provider :identity broker, a service which provides authentication for user’s OpenID identity (an URI/URL)
• Client :end user, person who can not remember hundreds or thousands of username/password pairs
• Client’s site :a site (which can also be a single page) owned/operated by user (where he/she has access to modify files or manage the content of the page) with an entry URL/URI functioning as claimed OpenID identity
• Delegation :a process of determining which identity provider to be used in authenticating user. In client’s site, delegation is determined through some codes inserted in the OpenID identity page (or the page which acts as OpenID URL)

Brief operation for OpenID authentication:

John Doe is trying to access private data in Site A which is a step ahead of its competitor by providing OpenID authentication. John is prompted with a form containing single field to fill, ie his OpenID identity. John writes his claimed URL and then submit the form. The claimed URL can be owned by John or just a single page provided by OpenID provider which enables John to authenticate using provider’s server.

In the claimed URL, there is extra header in the HTML which contain identity to be delegated and which server will authenticate the delegation or the OpenID server. Once this data is read, Site A will contact OpenID provider, asking if John is already logged in there. If he’s not, John will be prompted to provider’s authentication page to fill his credential (usually username and password in the provider’s site) and after successful login, John’s browser will be redirected back to Site A where he’s now able to access the private page.

To make this happen, the following conditions are necessary and related processes should occur on the background:

• Site A needs to have session or state recognition enabled so it can differ authenticated and unauthenticated users
• Site A needs to pass return URL to the OpenID server so that it will properly redirect user after authenticating
• OpenID server needs to pass parameter to the return URL so that site A can decide if user is authenticated or not

Err.. you said passwordless, but how can client authenticate at provider’s page? What input should be supplied? At this stage, we’re back with classical method, authentication with username/password registered at provider’s site. So, it’s not passwordless afterall? Yes, OpenID is not an account. It’s a mechanism to enable user authenticating him/herself by using a broker, ie OpenID identity provider, not directly at the site he’s currently visiting. This way, number of login credentials can be reduced to only one (or a few) provided by user’s pick of several OpenID providers.

Some other questions may pop up in your mind. How can provider and consumer trust each other? Can I trust my provider or which provider can be trusted? What code is put in client’s URL? Is this authentication safe? A slide show presentation from Simon Willison and David Recordon in OSCON 2007 provides more info about OpenID

OpenID Adoption
More and more software and software companies adopt OpenID for authentication process. Both pictures below show adoption comparison from 2006 to 2007

OpenID adoption in 2006

OpenID adoption in 2007

Thinking to deploy your own OpenID consumer after seeing above images?

OpenID for PHP Developers

Padraic Brady proposal for OpenID 2.0 is now reviewed in PEAR channel. Stas from Zend (who might also collaborate with Padraic) is also working for OpenID authentication component in Zend Framework. Let’s see how the development goes. More references to both technical and user guide about OpenID can be found in the next section

More References

1. Wikipedia entry about OpenID
2. Simon Willison’s entries about OpenID
3. openidenabled.com

Is It All About Passwordless?

Not yet. OpenID is not alone. A new company named Vidoop has introduced their mechanism for authenticaion based on grid images.

Vidoop grid image authentication

Basic idea for grid image authentication is visual imagery, assuming human is better in identifying and reckoning image than text. Probably true but I don’t think so. In the past I had seen similar approach offered by Spymac. They ask user to pick three icon images among others provided in a grid as password and then authenticate by clicking the icons in order user’s previously chosen. For me, that way is innovative. However, after several days of inactive login I totally forgot the icon order I pick, hence I got trouble in logging in. Spymac itself later disabled this authentication method and fell back to the conventional username/password.

Anyway, for those interested in knowing more about this authentication, you can simply watch Vidoop’s video cast or read a review in Tech Republic by Jason Hiner.

Note: this article has been updated on February 13th, 2008