“.NET Identity and Claims: A Beautiful Setup for Scalable Authentication Part 1”

In modern web applications, user authentication and authorization are critical to ensuring secure access to resources. Traditionally, user data (such as user ID, email, and roles) is retrieved from a database using methods like GetUserById. However, with the rise of token-based authentication, such as JSON Web Tokens (JWT), the way we handle authentication has evolved.

While JWTs are often stored in browser storage like localStorage or sessionStorage, I've chosen a different approach: storing the generated Identity token in a cookie. This method provides an added layer of security, as cookies are automatically managed by the browser and can be configured with attributes like HttpOnly, making them inaccessible to JavaScript. By doing this, I gain peace of mind knowing that JavaScript can’t easily access the token, reducing the risk of attacks like Cross-Site Scripting (XSS).

The setup:

setting up a IUserContext interface that will define GetCurrentUser will be a clean implementation on times you need the user object.

This is useful because instead of retrieving the user_object on the database by creating a method name GetUserById you can just simply access it through claims. I think this alone can have a good amount of impact on performance of your application minimizing database interactions.

Sample Code:

Clean right? :)

Also to add please take note of our new dependency injection starting from c#12 :) no need for declaration of private methods.

Enhanced Implementation of Claims: Adding Permissions/Policies

A powerful and efficient way to manage user permissions and policies is by embedding them directly into the token as claims. This eliminates the need to make additional database calls or external requests to verify user access, streamlining authorization checks on each request.

Concern: Wouldn't Adding Permissions Make the Token Too Large?

You might be wondering: Won’t adding permissions (usually stored as strings) to the token make it too large? This is indeed a valid concern, especially when you're storing the token in a cookie. Cookies have a size limit, typically around 4 KB. If you add a large number of permissions or lengthy permission strings, the token size could exceed this limit, potentially causing issues. Large tokens can lead to performance bottlenecks, including slower page load times on the client side and additional overhead on the server side for token validation.

Solution: Jason Taylor's Flexible Authorization

The solution is to leverage Jason Taylor’s Flexible Authorization framework, which provides a more efficient way of managing permissions. Instead of storing permissions as strings, you can store them as integer values that represent different permissions. By converting these integers to binary, you can encode multiple permissions into a much smaller space, dramatically reducing the token size while still keeping the flexibility of fine-grained access control.

I’ll be diving into this approach and sharing how to implement it in my next blog post, coming out next week. In the meantime, check out Jason Taylor’s Flexible ASP.NET Core Authorization for more details on how to apply this technique effectively.