Many websites offer features that are only available to users who first log-in to the system. In a typical application, user identity is confirmed ("authenticated") upon entering the username and password for the account. This approach is straightforward and works, but there are drawbacks. Users are usually required to remember a username/password for every website they use, which can be problematic.
OpenID is an open standard that defines a way that web-based applications can authenticate users by delegating the responsibility of authentication to identity providers. With OpenID, users have a single identity that can be used on any OpenID-enabled application, and they only need to remember one password.
In this article, I describe the OpenID authentication system and show how a web application built with Ruby on Rails can use OpenID to authenticate its users.
How OpenID works?
OpenID relies on the HTTP protocol to exchange messages between users and "identity providers." Consider a user named Bob, whose identity provider is my OpenID (www.myopenid.com). Bob uses the Drupal content management system that happens to be an OpenID consumer. Here's the general workflow when Bob logs into his Drupal account through OpenID:
The following diagram best explains how OpenID works:
Benefits of using OpenID:
You will be glad to know that Google also provides OpenID. Use http://openid-provider.appspot.com to know your OpenID provided by Google.
Reference: Dr Dobb's
OpenID is an open standard that defines a way that web-based applications can authenticate users by delegating the responsibility of authentication to identity providers. With OpenID, users have a single identity that can be used on any OpenID-enabled application, and they only need to remember one password.
In this article, I describe the OpenID authentication system and show how a web application built with Ruby on Rails can use OpenID to authenticate its users.
How OpenID works?
OpenID relies on the HTTP protocol to exchange messages between users and "identity providers." Consider a user named Bob, whose identity provider is my OpenID (www.myopenid.com). Bob uses the Drupal content management system that happens to be an OpenID consumer. Here's the general workflow when Bob logs into his Drupal account through OpenID:
- Arthur visits any OpenID-driven website.
- Arthur enters his OpenID identity URI, "arthur-id.myopenid.com," in the login form and clicks a Submit button. That's his OpenID identity URI, which looks like a website address but identifies Bob and his identity provider.
- Arthur's web browser is redirected to a web page served by myOpenID, where he is prompted for his password.
- Arthur enters his OpenID password and clicks a Submit button.
- myOpenID confirms Arthur's password, and his web browser is redirected to the website he opened with automated log-in.
OpenID is an open standard that defines a way that web-based applications can authenticate users via a single identity. OpenID provides several benefits to users and developers. Users only need to remember one username (their identity URI) and password to access multiple applications. With a simple cookie and Remember Me checkbox, an OpenID identity provider can act as a convenient Single Sign-On (SSO) solution for someone who uses multiple OpenID consumers.
OpenID identity providers are responsible for the authentication of users It's nowadays common for web apps to offer OpenID support as an alternative to traditional authentication methods, but letting experts handle password security reduces the risk of accounts being compromised.You will be glad to know that Google also provides OpenID. Use http://openid-provider.appspot.com to know your OpenID provided by Google.