Are ASP.NET Core claims reliable and secure from tampering?

Question

I have several different types of users (InternalUser, Clinician, and Patient) that can log into my website, so, for each type of user, I've created a user class that inherits from ApplicationUser.

If a logged-in user comes to the website's main page (https://example.com/) then the MVC controller code needs to figure out which type of user it is so that it can return a redirect to the correct "main" page (https://example.com/clinician, https://example.com/patient, etc.).

It seems reasonable to me to use a claim as an easy, low-cost way to discriminate the user type in the controller, without having to load the current user from the database. When I register a user, I add a claim that represents the user "type":

await _userManager.AddClaimAsync("ihi:user_type", "clinician");

Then, in the controller, I check the claim:

[Authorize]
public IActionResult Index()
{
    if (User.HasClaim("ihi:user_type", "clinician")) return Redirect("...");
    if (User.HasClaim("ihi:user_type", "patient")) return Redirect("...");
    if (User.HasClaim("ihi:user_type", "internal")) return Redirect("...");

    throw new InternalErrorException("Logged in user is not in a recognized user role");
}

I have a couple of questions regarding this scheme:

1. Is this a reasonable approach?
2. This scheme (both the [Authorize] attribute and my claims checks) relies on looking at the value of a cookie. Is the data stored in that cookie reasonably safe from tampering? (I would hope so, otherwise an attacker could modify the cookie and game the Identity system.)

Answer 1

Is this a reasonable approach?

Yes, that's a common approach, given that the Identity cookie has all claims inside.

Is the data stored in that cookie reasonably safe from tampering?

From the docs:

SignInAsync creates an encrypted cookie and adds it to the current response. If you don't specify an AuthenticationScheme, the default scheme is used.

Under the covers, the encryption used is ASP.NET Core's Data Protection system.

As you can see here, there are lots of configurations you can do to the Data Protection system, including using certificates to create/protect the keys used to encrypt the Identity cookie, and using ephemeral keys so all cookies are forever lost upon shutting down the application.

Overall, unless you have some high level of security needed, the default settings are more than enough.