I got confused many times to differentiate between Claim and Security token, and what exactly those means.
While reading a very interesting book by Microsoft “a guide to claims-based identity and access control – Authentication and Authorization for Services and the Web”
I will discuss a real life example which explains Claim based easily and how the it tailored to be used in software in efficient way:
A Familiar Example
Claims-based identity is all around us. A very familiar analogy is the authentication protocol you follow each time you visit an airport. You can’t simply walk up to the gate and present your passport or driver’s license. Instead, you must first check in at the ticket counter. Here, you present whatever credential makes sense. If you’re going overseas, you show your passport. For domestic flights, you present your driver’s license. After verifying that your picture ID matches your face (authentication), the agent looks up your flight and verifies that you’ve paid for a ticket (authorization). Assuming all is in order, you receive a boarding pass that you take to the gate. A boarding pass is very informative. Gate agents know your name and frequent flyer number (authentication and personalization), your flight number and seating priority (authorization), and perhaps even more. The gate agents have everything that they need to do their jobs efficiently.
Look at this
Other article might be useful
There is also special information on the boarding pass. It is encoded in the bar code and/or the magnetic strip on the back. This information (such as a boarding serial number) proves that the pass was issued by the airline and is not a forgery. In essence, a boarding pass is a signed set of claims made by the airline about you. It states that you are allowed to board a particular flight at a particular time and sit in a particular seat. Of course, agents don’t need to think very deeply about this. They simply validate your boarding pass, read the claims on it, and let you board the plane. It’s also important to note that there may be more than one way of obtaining the signed set of claims that is your boarding pass. You might go to the ticket counter at the airport, or you might use the airline’s web site and print your boarding pass at home. The gate agents boarding the flight don’t care how the boarding pass was created; they don’t care which issuer you used, as long as it is trusted by the airline. They only care that it is an authentic set of claims that give you permission to get on the plane.
In software, this bundle of claims is called a security token. Each security token is signed by the issuer who created it. A claims-based application considers users to be authenticated if they present a valid, signed security token from a trusted issuer. Figure 1 shows the basic pattern for using claims.
For an application developer, the advantage of this system is clear: your application doesn’t need to worry about what sort of credentials the user presents. Someone who determines your company’s security policy can make those rules, and buy or build the issuer. Your application simply receives the equivalent of a boarding pass. No matter what authentication protocol was used, Kerberos, SSL, forms authentication, or something more exotic, the application gets a signed set of claims that has the information it needs about the user.
This example is a very simple describe the claim based model 🙂