Web Authentication

Federated ID

Federated ID, also called Federated Identity Management (FIM), allows a Service Provider (SP) to offer a service without implementing its own authentication system, and to instead trust another entity—an Identity Provider (IdP)—to provide authenticated users to them.

A user’s authentication process across multiple IT systems or even organizations.

For example, a traveler could be a flight passenger as well as a hotel guest. If the airline and the hotel use a federated identity management system, this means that they have a contracted mutual trust in each other’s authentication of the user. The traveler could identify him/herself once as a customer for booking the flight and this identity can be carried over to be used for the reservation of a hotel room.

If that seems confusing, imagine two companies: IdentiCorp and ServiceInc. ServiceInc has great services, but they don’t like the idea of managing passwords for users. IdentiCorp, on the other hand, provides username and password management as their main business.

So these two companies come to an agreement—ServiceInc will allow people to log in to their websites using IdentiCorp credentials. This means when someone visits ServiceInc’s website and they haven’t yet authenticated to the site, they are redirected to IdentiCorp where they enter their IdentiCorp credentials. Once they authenticate, IdentiCorp then redirects the user back to ServiceInc, and tells ServiceInc in a cryptographicall secure way that, “this user is o.k., according to me.” ServiceInc trusts IdentiCorp, so the user is able to do what they need to do within ServiceInc.

The term “identity federation” is by design a generic term, and is not bound to any one specific protocol, technology, implementation or company.


Rather than being something completely separate, OpenID is just one type of Federated Identity system. OpenID is focused more on the consumer market, whereas FID-proper is focused on the enterprise–but the concept is the same. It offers the ability for users to log into one website (Facebook, for example) using credentials from another website, such as Google.

How It Works

  •     You give the website you want to use your OpenID
  • It goes to that location to see where you need to authenticate
  • It sends you to that location (your OpenID provider)
  • You authenticate there
  • Your OpenID Identity Provider tells the website you want to use that you’re ok (but without giving it your password)
  • You are now able to use the website without having to give it any password

Some observers have suggested that OpenID has security weaknesses and may prove vulnerable to phishing attacks.

OpenID authentication is now used and provided by several large websites. Providers include AOL, BBC, Google, IBM, MySpace, Orange, PayPal, VeriSign, LiveJournal, and Yahoo!


Many confuse OpenID and OAuth, but although they can be used together they are actually quite distinct from each other. While OpenID’s main purpose is to reduce the number of identities people need to maintain online, OAuth’s main goal is to eliminate the need to give website A your username and password for website B, and determines what website B can get from A once it’s been allowed access.

To simplify for the infosec geeks, OpenID is about authentication, and OAuth is about authorization.

The sharing scenario comes up quite often within social networking services, which often benefit from leveraging each other. Want to see if your Twitter friends are on Facebook?

OAuth solves this by:

  •  Allowing functionality to be shared between websites without passing your password between them, and
  • Giving only limited access to features between websites, so it’s not “all or nothing”

This way you can give a social site like Facebook access to your images on an Image site like Flickr without giving Facebook your actual Flickr credentials.

The diagram below shows how Google’s description of the OpenID process, including the sending and receiving of OAuth tokens. The key there is that the OAuth piece was optional since it’s a separate authorization component added on top of the OpenID authentication protocol.

Source :- Wiki