Thread by @davidfowl

This thread was good because it helped clarify my thinking. There are 2 phases (for simplicity) where ClaimsPrincipal shows up:
- The authentication flow
- The authorization flow

Claims are typically used to store authentication data. #dotnet #aspnetcore 🧵👇🏾

https://twitter.com/davidfowl/status/1540860499256119296

That data is then used to look up more user information (profile data) usually store in a database/cache. This profile data usually also contains permissions and authorization rules are then run over this user for different types of application "resources".

These resources typically include (but are not restricted to):
- The HTTP endpoint
- Some business object

The authorization process usually needs access to all user profile information including permissions to do authorization checks.

ASP.NET's authentication system produces a
ClaimsPrincipal and the authorization system flows that ClaimsPrincipal to your code. This encourages users to put more things in claims as it's the only thing that flows in the first class way everywhere in the stack.

Putting more things in claims avoids more database round trips per request as the associated data is stashed at the protocol layer (the cookie, the JWT token etc). It increases the size of these tokens to avoid a potential database round trip per request.

This leads to people storing permissions in claims which makes doing authorization checks much easier as permission checks turn into checks for certain claims.
There's a philosophical debate about what should and should not be a claim and that leads to confusion.

The fact is, when the ClaimsPrincipal is used at the authentication layer, it's about the wire protocol. Data is read from the wire and turned into a ClaimsPrincipal and data is read from the ClaimsPrincipal and persisted back over the wire.

The ClaimsPrincipal is also used as an "exchange type" in .NET. It's the universal representation of an identity in the system so it's easy to pass it around everywhere.

So that leads us back to the original problem: Which user representation should developers be using for authorization checks? How does that user representation reach their authorization handlers?

This is what needs to be made clearer with docs and samples and possibly framework features.

Thanks for coming to my ted talk.

Thanks for the insights @BrockLAllen !