News

What is OpenID? How to use OpenID SSO in your organisation

Michael Cobb, Application Security

A thorny problem for many organisations running a website is the registration process for new users.

The marketing department wants to capture as much information about each new user as possible, but a lengthy registration form discourages people from signing up. The buying department is keen to get feedback via users’ comments, but who’s going to leave a comment that takes three minutes to write if registration takes five? Finally, the IT department may not have the in-house knowledge or resources to create a secure login process to store user passwords and data online.

One option may be to configure the login system to accept OpenID, but what is OpenID, and how does it work? OpenID allows users to sign in to multiple sites using just one identity, so users can sign in with an existing Facebook, Google, Yahoo, Twitter or other OpenID account. A new visitor to your site with an existing OpenID account doesn’t need to create another username and password or check his or her email for an account verification message, all of which are obstacles to getting people to register.

Sites offering OpenID sign-in don’t see the user's password, yet can get access to a rich set of user data that should keep the marketing department happy. Activity Streams can be implemented on top of OpenID to allow users who authenticate with an OpenID to publish information from your site to their social networks, helping to promote it.

How OpenID works
The OpenID protocol allows a user to prove he or she owns a specific URL. This URL can be used as an authentication credential, so when a site needs to know who a user is, the user can prove his or her identity with their OpenID URL. The method of authentication may vary, but typically the site, known as the relying party, fetches the URL to discover who the OpenID provider is; it then uses Diffie-Hellman key exchange to establish a shared secret with the OpenID provider to sign messages between them. If this is the first time a user is signing in using OpenID, he or she is redirected to the OpenID provider to sign in. The user is then redirected back to the relying party's site with an assertion that authentication was approved, which the relying party can verify.

Login is performed over SSL, and users can usually configure their OpenID accounts to request two-factor authentication; automated call verification and soft tokens, such as an information card, are popular options. The user can also control how much personal information is sent to the relying party by selecting which “persona” he or she wishes to send. This is another advantage, as users only need to update their profile information -- such as address -- in one location, not on every online shopping site they've used.

There is some scepticism around the concept of OpenID security, but the positives may overwhelm the negatives, given the chronic weaknesses in today’s common authentication mechanisms where users have to remember a myriad of passwords, most of which are easily guessable and offer little to no security at all. However, the following are some of the issues that have been raised.

An OpenID-enabled website works by delegating authentication to an OpenID provider, adding another party to the authentication process. The first time a user logs in using OpenID while browsing, he or she must leave that particular website to authenticate: This creates an opportunity for a phishing attack, wherein the user is tricked into providing his or her OpenID credentials to a malicious site designed to look like the OpenID provider. A compromise of an OpenID account gives an attacker access to all the sites affiliated with that OpenID. Also, if an OpenID provider suffers a power outage, network failure or DDoS attack, users can’t log in to sites that depend on that authentication server until it’s back online.

Once users sign in to their OpenID account, they can access other sites that accept OpenID without having to go through the full sign-in process. Thus, the user could fall victim to a cross-site request forgery (CSRF) attack.

But OpenID isn’t any more prone to phishing or cross-site scripting-based attacks than other online services. All websites are vulnerable to similar attacks, but OpenID providers specialise in identity management and offer far better security and resilience than the average website storing usernames and passwords.

Having a well-protected OpenID is far better than having weak, similar and often shared passwords used across multiple sites that have varying security measures protecting them. We have seen with Facebook that a compromise at one site can lead to a compromise of others. Yes, OpenID is a single point of failure, but may, on the whole, present less risk.

OpenID security best practices
When implementing OpenID, either as a means of authenticating yourself, your staff or visitors to your site, be sure to choose an OpenID provider you trust. Begin by reading the provider's privacy policy to ensure it will never sell or reveal any of your account or personal information to a third party without your permission.

OpenID SSO is still the only viable option for a decentralized Internet-wide single sign-on system, and it can make online life a lot easier and more secure. At the start of 2010, there were already more than a billion OpenID-enabled accounts on the Internet and approximately nine million sites had integrated OpenID consumer support. Due to the huge popularity of sites like Twitter, Google and Facebook, it is possible to offer login only via OpenID, meaning you wouldn’t have to store passwords or implement account management and password-recovery systems at all.


Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Read More

 

COMMENTS powered by Disqus  //  Commenting policy