@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?"
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
