OpenID

What is OpenID?
OpenID eliminates the need for multiple usernames across different websites, simplifying your online experience.
You get to choose the OpenID Provider that best meets your needs and most importantly that you trust. At the same time, your OpenID can stay with you, no matter which Provider you move to. And best of all, the OpenID technology is not proprietary and is completely free.
For businesses, this means a lower cost of password and account management, while drawing new web traffic. OpenID lowers user frustration by letting users have control of their login.
For geeks, OpenID is an open, decentralized, free framework for user-centric digital identity. OpenID takes advantage of already existing internet technology (URI, HTTP, SSL, Diffie-Hellman) and realizes that people are already creating identities for themselves whether it be at their blog, photostream, profile page, etc. With OpenID you can easily transform one of these existing URIs into an account which can be used at sites which support OpenID logins.
OpenID is still in the adoption phase and is becoming more and more popular, as large organizations like AOL, Microsoft, Sun, Novell, etc. begin to accept and provide OpenIDs. Today it is estimated that there are over 160-million OpenID enabled URIs with nearly ten-thousand sites supporting OpenID logins.

OpenID is an open protocol that enables a person to use a URL as an identity and use the same identity (the URL) at multiple web sites that support OpenID. Web- enabled applications can use the identity URL for authentication, authorization, and other purposes. It is a relatively new concept which puts the control of the identity into the hands of its owner, the end user. The owner of the identity can decide, and has control over, which information should be presented to an application or web site for authentication purpose.
Among other things, OpenID enables owners to:
· Login to web-enabled applications and web sites without ever entering any username and password information.
· Enable web sites to request information from a user; and empowering the user to choose which information is to be sent to a web site during authentication/authorization process.
· Chose which sets of information (also known as profiles or cards) to be sent to different web sites, based upon need and risk level.
· Allows implementation of graded and risk-based authorization.
· Implement an alternate to single sign on (SSO) for multiple applications within an organization.
· Implement an alternate mechanism for cross-company authentication (CCA) for affiliates and business partners.
· Integrate applications into the OpenID system using a simple and elegant mechanism.
· Lower cost of implementation and maintenance of an identity management solution.

Who Owns or Controls OpenID?
OpenID has arisen from the open source community to solve the problems that could not be easily solved by other existing technologies. OpenID is a lightweight method of identifying individuals that uses the same technology framework that is used to identify websites. As such, OpenID is not owned by anyone, nor should it be. Today, anyone can choose to be an OpenID user or an OpenID Provider for free without having to register or be approved by any organization.
The OpenID Foundation was formed to assist the open source model by providing a legal entity to be the steward for the community by providing needed infrastructure and generally helping to promote and support expanded adoption of OpenID.
As Brad Fitzpatrick (the father of OpenID) said, “Nobody should own this. Nobody’s planning on making any money from this. The goal is to release every part of this under the most liberal licenses possible, so there’s no money or licensing or registering required to play. It benefits the community as a whole if something like this exists, and we’re all a part of the community.”


Terminology

1. Identifier : URI or XRI
2. Replying party (RP, Consumer)
3. openID provider (Identity provider, openID server)

There are three major components in any OpenID system: Consumer, Identity Provider, and User Agent. These components interact with each other during the authentication process. Roles for these components are explained next.

1. The Consumer, which is the web site where you are trying to login, interacts with the Identity Provider and the User Agent (the web browser). An End User will try to login to the Consumer web sites using OpenID. During the authentication process, the Consumer will send some messages to the Identity Provider directly as well as via User Agent with the help of HTTP redirect messages.

2. The Identity Provider is the OpenID server that holds an End User’s
credentials. The Identity Provider will validate the ownership of an identity URL to the Consumer using two basic mechanisms which we shall discuss later in this chapter.

3. An End User will interact with the Consumer and Identity Provider using the User Agent. The User Agent is your web browser.

During the authentication process, the browser acts as the middle man between the Identity Provider and the Consumer web site for some messages. Typically, a Consumer will interact with the web browser as well as the Identity Provider during authentication process. However in some cases, the Consumer may use cached keys to authenticate a user without any direct communication with the Identity Provider.

 

There are two basic communications methods among different entities in an OpenID system:

1. Direct Communication
2. Indirect Communication.

In the Direct Communication mechanism, two entities directly talk to each other using the HTTP protocol. The HTTP POST method is used for direct communication.

With the Indirect Communications, two entities talk to each other via a third entity. This third entity is typically the web browser. Indirect communication may happen via HTTP Redirect or via HTML Form redirection.

OpenID has two major modes of operation: the Dumb mode and the Smart mode. These modes are based upon how intelligent the Consumer is. In Dumb mode, as the name implies, the consumer is not that smart and has to perform few additional steps every time a user logs in. In Smart mode, the Consumer keeps state information and caches shared keys for future use.

Dumb Mode Communications Flow

1. You visit the Consumer web site where you want to login.
2. The web site presents a web page where you enter your identity URL. Typically, you will enter your Identity URL (for ex http://myvikas.myopenid.com) and click on Login button. Different web sites may have different types of web pages but the process will remain the same.
3. The Consumer web site will clean up the Identifier URL and fetch the information from its current URL location. . In OpenID specification version 2, another XML protocol, known as Yadis, can also be used at this stage for service discovery.
4. After fetching the page, the Consumer will then parse it and determine the location of Identity Provider (OpenID Server). This parsing process is also called discovery. After parsing, the Consumer will then redirect the web browser to the Identity Provider to obtain the assertion information. This happens using the HTTP GET method. Optionally, the consumer may establish a connection with the identity provider at this point and exchange a shared secret for further communication. This is shown with a dotted line in Figure and marked as step 4a.
5. If the end user is not already logged into to Identity Provider, the Identity Provider may ask the End User to login. However, it should be noted that this part is outside the OpenID specifications and it is left to the Identity Provider to decide how to authenticate the End User. In some circumstances, if you have already logged into the Identity Provider web site, this part may be skipped altogether.
6. The Identity Provider website will return the assertion information with its signature to the Consumer via browser redirect. This assertion will represent either an authentication success or failure. The HTTP GET method is used in this step as well. Note that this is the Indirect Communication between Identity Provider and the Consumer.
7. During successful assertion, the Consumer will establish a direct connection with the Identity Provider, preferably over a secure SSL session. It will request the authentication information directly from the Identity Provider and compare it with the assertion information it received via User Agent (web browser). This is to double check the validity of the assertion in case a User Agent (or a malicious attacker) is trying to cheat.
8. If there is a match in the previous step, the End User will login to the website. Otherwise the login will fail.

Smart mode communication is almost same except a change in point-7. It is :
After a successful assertion, the Consumer verifies the assertion using the cached shared key. If there is a match in the previous step, the End User will login to the web site. Otherwise login will fail.

Detailed diagram of openID protocol:

There are a lots  of terms like XRDS, yadis described in this diagram. I will expore these terms soon in deeper detail.

Mashup

What is a Mashup?


A mashup is a website or web application that seamlessly combines content from more than one source into an integrated experience.Content used in mashups is typically sourced from a third party via a public interface or API. Other methods of sourcing content for mashups include Web feeds (e.g. RSS or Atom) and JavaScript.Many people are experimenting with mashups using eBay, Amazon, Google, and Yahoos APIs. The increased use and popularity of mashups has increased with the emergence of Web 2.0, which is characterized by active user participation and interaction.The architecture of mashup web applications is always composed of three parts:• The content provider: it is the source of the data. Data is made available using an API and different Web-protocols such as RSS, REST, and Web Service• The mashup site: is the web application that provides the new service using different data sources that are not owned by it.• The client web browser: is the user interface of the mashup. In a web-application, the content can be mashed by the client web browsers using client side web language for example JavaScript.Types of Mashups:There are many types of mashups, such as consumer mashups, data mashups, and business mashups. Consumer mashups: Consumer mashups combine different forms of media from multiple sources and combine them into a single graphical interface. Consumer mashups are aimed at the general public, that is, consumers. Examples of consumer mashups include the many Google Maps applications, iGuide and Radioclouds.Data mashups:Data mashups combine similar types of media and information from multiple sources into a single graphical representation. An example of a data mashup is the Havaria Information Services' AlertMap. which combines current data from over 200 sources related to severe weather conditions, biohazard threats and seismic information from around the world, and displays them on a single map of the world. Another example of a data mashup is Yahoo PipesBusiness mashups:Business mashups focus on various forms of data aggregation into a single presentation, but also allow for collaborative function ability amongst businesses and developers. Serena Software is a company involved in the business mashup industry.

OAUTH

OAUTH is an “open protocol to allow secure API authorization in a simple and standard method from deasktop and web applications.”

What does OAuth really mean?
Well, lets break the above description down into some key phrases and the pieces should come together.
A "Protocol" is a standardized method for the communication of two computers. For instance HTTP is the standardized way of a webserver communicating with your computer when you browse a website.
"Open” comes from the fact that this protocol is open source and can be viewed, downloaded, and maintained by anyone who is willing to take up the torch.
“Secure API authorization” is the functionality that OAuth.net gives to its stakeholders - the ability for a developer to download OAuth.net and secure their API access without having to write a unique (and possibly bug filled) authentication!

The key tenet of these schemes and of OAuth is that users should be able to share their data with third-party applications without sharing their passwords.

OAuth allows you to share your private resources (photos, videos, contact list, bank accounts) stored on one site with another site without having to hand out your username and password. There are many reasons why one should not share their private credentials. Giving your email account password to a social network site so they can look up your friends is the same thing as going to dinner and giving your ATM card and PIN code to the waiter when it’s time to pay. Any restaurant asking for your PIN code will go out of business, but when it comes to the web, users put themselves at risk sharing the same private information. OAuth to the rescue.

Both the valet key and ATM cards are good metaphors for OAuth from a user perspective. Instead of giving your ATM card and PIN code, the card can double as a credit card with a signature authorization. Just like your username and password provide full access to your resources, your ATM card and PIN code provide you with great control over your bank accounts – much more than just charging goods. But when you replace the PIN code with your signature, the card becomes very limited and can only be used for limited access.
Users don’t care about protocols and standards – they care about better experience with enhanced privacy and security. This is exactly what OAuth sets to achieve. With web services on the rise, people expect their services to work together in order to accomplish something new. Instead of using a single site for all their online needs, users use one site for their photos, another for videos, another for email, and so on. No one site can do everything better. In order to enable this kind of integration, sites need to access the user resources from other sites, and those are many times protects (private family photos, work documents, bank records). They need a key to get in.
The key used by users is usually a combination of username and password. This can be an OpenID or any other login credential. But this key is too powerful and unrestrictive to share around. It also cannot be unshared once handed out except for changing it which will void access to every site, not just the one the user intends to block. OAuth addresses that by allowing users to hand out tokens instead. Each token grants access to a specific site (a video editing site) for specific resources (just videos from last weekend) and for a defined duration (the next 2 hours).
Unlike OpenID where users must do something first - get an OpenID identity they can use to sign-into sites – OAuth is completely transparent to the users. In many cases (if done right), the end-user will not know anything about OAuth, what it is or how it works. The user experience will be specific to the implementation of both the site requesting access and the one storing the resources, and adjusted to the device being used (web browser, mobile phone, PDA, set-top box).

A typical example is when a user wants to print a photo stored on another site. The interaction goes something like this: the user signs into the printer website and place an order for prints. The printer website asks which photos to print and the user chooses the name of the site where her photos are stored (from the list of sites supported by the printer). The printer website sends the user to the photo site to grant access. At the photo site the user signs into her account and is asked if she really wants to share her photos with the printer. If she agrees, she is sent back to the printer site which can now access the photos. At no point did the user share her username and password with the printer site.
Some Definitions
Service Provider: A web application that allows access via OAuth.
User: An individual who has an account with the Service Provider.
Consumer: A website or application that uses OAuth to access the Service Provider on behalf of the User.
Protected Resource(s): Data controlled by the Service Provider, which the Consumer can access through authentication.
Consumer Developer: An individual or organization that implements a Consumer.
Consumer Key: A value used by the Consumer to identify itself to the Service Provider.
Consumer Secret: A secret used by the Consumer to establish ownership of the Consumer Key. Request Token: A value used by the Consumer to obtain authorization from the User, and exchanged for an Access Token.
Access Token: A value used by the Consumer to gain access to the Protected Resources on behalf of the User, instead of using the User’s Service Provider credentials.
Token Secret: A secret used by the Consumer to establish ownership of a given Token.
OAuth Protocol Parameters: Parameters with names beginning with oauth_.

There are some libraries develolped for implementing OAUTH. I recommennd DNOA (DontNetOpenAuth) written by Andrw Arnott. You can even get the Full source code of this including Mock tests as it is Open Source.
I have implemented OAuth and OpenID in one of my project using this DotNetOpenAuth library. To get it please write to me at cybertechie.india@gmail.com