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

@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.

---

For a 5 years boy, ask him to assume he joined a new school by signing the application by his parents. After approval from school management for his application, he gets a access card which contains all the below information which we can call it CLAIMS to enter into the school.

NAME of the BOY is BOB. SCHOOL NAME IS MONTISSORI HIGH SCHOOL CLASS IS 8TH GRADE

On first day of his school while he walks into the school, he swiped his access card and the gates opened, means he has been CLAIMED AS one of the person from the school. In this way he is an AUTHENTICATED PERSON to enter into the school.

After reaching to his class, he used access card to enter into each class, but at 8th Standard Class doors opened as he Claimed to be from 8th Standard.

In the school, he is only AUTHORIZED to enter into his class as he is now studying 8th Standard. And if he try to enter into 6th Standard, the school teacher WON'T AUTHORIZE him.

---

As non-technical as possible:

If you were to describe anything about who you are and what you were allowed to see or do, each of those things would be something that you were "claiming" to be true, and thus each "thing" on that list would be a "claim".

Anytime you tell someone something about yourself or "claim" that you're allowed to see or do something, you hand them your list of claims. They will verify with an authority that your claims are true and if they are, they'll believe anything on that list of claims. So if you claim that you're Brad Pitt, your list of claims says that you're Brad Pitt, and it was verified with the authority that your claims are all true -- then they will believe that you're Brad Pitt along with anything else in that list.

Claim: what you claim to be true. This can be a piece of information or a description of a permission you're claiming to have. The system to which you present your claims only need to understand what the claim is/means and also be able to verify with the authority.

Authority: The system that puts your list of claims together and signs it which basically says "On my authority, everything in this list is true." So long as the system reading the claims can verify with the authority that the signature is correct, then everything in the list of claims will be considered authentic and true.

Also, let's not call it "claims based authentication", instead let's call it "claims based identity".

Slightly more technical:

So now in this process, you authenticate using some sort of mechanism (username/password, client secret, certificate, etc.) and that gives you a token that proves you are who you say you are. Then, you trade that access token for an ID token. That process will use your identity to find and build a list of claims, sign it and then hand you back an ID token that has all of your claims.

As the authorization step, depending on how it is implemented, the resource will look at your ID token (claims) and then check if you have the necessary claims to access that resource.

So for example, if the resource "CastleBlack/CommandersTower" says that "you have to have access to castle black and be lord commander, then it's going to look at your list of claims to see if both of those things are true.

As you see, "claims" can be anything. It can be a role, it can be a fact, it can be a flag. It's just a list of key-value pairs and the "value" is optional. Sometimes it's just about seeing if the claim exists:

claims : [
    {"type": "name", "value": "Jon Snow"},
    {"type": "home", "value": "Winterfell, The North, Westeros"},   
    {"type": "email", "value": "jon@nightswatch-veterans.org"},
    {"type": "role", "value": "veteran;deserter;"},
    {"type": "department", "value": "none"},    
    {"type": "allowEntry", "value": "true"},
    {"type": "access", "value": "castleblack;eastwatch;"}
]

So if Jon logged in and tries to access the resource described above, he would be denied because, while he is who he says he is and he does have access to castle black, he is no longer lord commander nor does he have explicit access to the commander's tower, and thus cannot implicitly enter the lord commander's tower.

More specifically, "CastleBlack" would probably be a [larger] scope, and each area would be a specific permission, but that's a different discussion.

How each application deals with access is going to be different, but it will use claims to do it.

---

Considering that a claim is an attribute that tells you something about the user (the name, age, ethnicity, etc) you work against a security token service to validate those claims and also used them for authorization apart from authentication.

The following excerpt is taken from Wikipedia (http://en.wikipedia.org/wiki/Claims-based_identity) and its the best analogy I found so far

"To better understand the concept of security token service, consider the analogy of a night club with a doorman. The doorman wants to prevent under-age patrons from entry. To facilitate this he requests a patron to present a driver's license, health insurance card or other identification (the token) that has been issued by a trusted third party (the security token service) such as the provincial or state vehicle license department, health department or insurance company. The nightclub is thus alleviated of the responsibility of determining the patron's age. It only has to trust the issuing authority (and of course make its own judgment of the authenticity of the token presented). With these two steps completed the nightclub has successfully authenticated the patron with regard to the claim that he or she is of legal drinking age.

Continuing the analogy, the nightclub may have a membership system, and certain members may be regular or VIP. The doorman might ask for another token, the membership card, which might make another claim; that the member is a VIP. In this case the trusted issuing authority of the token would probably be the club itself. If the membership card makes the claim that the patron is a VIP, then the club can react accordingly, translating the authenticated VIP membership claim to a permission such as the patron being permitted to sit in the exclusive lounge area and be served free drinks."

---