Explain "claims-based authentication" to a 5-year-old

Well, not exactly to a 5-year-old, but please avoid buzzword and enterprisespeak if possible.

Claims-based authentication seems to be all the rage now, but I could not find a simple and down-to-earth explanation of what it actually is, how is it different from what we have now (I assume "what we have now" to be role-based authentication), what are the benefits of using it, etc.

@Marnix has a pretty good answer, but to step away from the technical aspect of it:

Claims Based Authentication is about defining who you trust to give you accurate information about identity, and only ever using that information provided. My (the) go-to example is at a bar. Imagine for a moment that you want to get a beer at the bar. In theory the bartender should ask you for proof of age. How do you prove it? Well, one option is to have the bartender cut you in half and count the number of rings, but there could be some problems with that. The other option is for you to write down your birthday on a piece of paper to which the bartender approves or disapproves. The third option is to go to the government, get an ID card, and then present the ID to the bartender.

Some may laugh at the idea of just writing your birthday on a piece of paper, but this is what is happening when you are authenticating users within the application itself because it is up to the bartender (or your application) to trust the piece of paper. However, we trust the government's assertion that the birthday on the ID is valid, and the ID is for the person requesting the drink. For all intents and purposes, the bartender (or application) doesn't really care how the authentication occurred because of the trust. The bartender knows nothing about you except your date of birth because that's all the bartender needs to know. Now, the bartender could store information that they think is important to them, like your favorite drink, but the government doesn't care (as it isn't the authoritative source), so the bartender stores that information in his own way.

The key to CBA is "who is the authoritative source of the identity?"

(This is my personal take on this, others may differ. Please post other viewpoints as separate answers.)

Claims-based identity/authentication/authorization is about separating the maintenance of user authorizations and user sign-in out of a (web) application, by turning authentication/authorization into a separate (web) service.

So for example, when I browse to a claims-enabled web application for the first time, it will redirect my browser to a 'logon service' which it trusts. I will authenticate to that service (using Windows authentication, a smart card, or whatever), and in response it sends back a 'token', which the browser sends back to the web application. Now the web application checks that the token is digitally signed by its trusted logon service, and then looks at the 'claims' in the token. Based purely on those claims, the application decides what functionality the user is offered.

The claims will almost always include the user's identity, often there are also authorization-related claims ('this user may view Sales data, but not update it'), and sometimes other information as well ('shoe size = 42').

The key point is that the application does not know nor care how the user was authenticated, nor how the authorizations are administrated: it only uses the information from the claims in the signed token to determine who the user is and/or what the user may see or do and/or any other information about the user.

(Yes, I'm assuming a pretty intelligent and well-informed 5-year-old here. :-)

The following real world example is taken from A Guide to Claims-Based Identity and Access Control (2nd Edition).

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.

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.