Best Practices for Roles vs. Claims in ASP.NET Identity

Question

I am completely new to the use of claims in ASP.NETIdentity and want to get an idea of best practices in the use of Roles and/or Claims.

After all this reading, I still have questions like...

Q: Do we no longer use Roles?
Q: If so, why are Roles still offered?
Q: Should we only use Claims?
Q: Should we use Roles & Claims together?

My initial thought is that we "should" use them together. I see Claims as sub-categories to the Roles they support.

FOR EXAMPLE:
Role: Accounting
Claims: CanUpdateLedger, CanOnlyReadLedger, CanDeleteFromLedger

Q: Are they intended to be mutually exclusive?
Q: Or is it better to go Claims ONLY and "fully-qualify" you claims?
Q: So what are the best practices here?

EXAMPLE: Using Roles & Claims Together
Of course, you would have to write your own Attribute logic for this...

[Authorize(Roles="Accounting")]
[ClaimAuthorize(Permission="CanUpdateLedger")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}

EXAMPLE: Fully-Qualifying Your Claims

[ClaimAuthorize(Permission="Accounting.Ledger.CanUpdate")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}

Answer 1

A role is a symbolic category that collects together users who share the same levels of security privileges. Role-based authorization requires first identifying the user, then ascertaining the roles to which the user is assigned, and finally comparing those roles to the roles that are authorized to access a resource.

In contrast, a claim is not group based, rather it is identity based.

from Microsoft documentation:

When an identity is created it may be assigned one or more claims issued by a trusted party. A claim is a name value pair that represents what the subject is, not what the subject can do.

A security check can later determine the right to access a resource based on the value of one or more claims.

You can use both in concert, or use one type in some situations and the other in other situations. It mostly depends on the inter-operation with other systems and your management strategy. For example, it might be easier for a manager to manage a list of users assigned to a role than it is to manage who has a specific Claim assigned. Claims can be very useful in a RESTful scenario where you can assign a claim to a client, and the client can then present the claim for authorization rather than passing the Username and Password for every request.

Answer 2

As @Claies perfectly explained, claims could be a more descriptive and is a deep kind of role. I think about them as your roles ids. I have a gym id, so I belong to the members role. I am also in the kickboxing lessons, so I have a kickboxing id claim for them. My application would need the declaration of a new role to fit my membership rights. Instead, I have ids for each group class that i belong to, instead of lots of new membership types. That is why claims fit better for me.

There is a a great explanation video of Barry Dorrans, talking about the advantage of using claims over roles. He also states that roles, are still in .NET for backward compatibility. The video is very informative about the way claims, roles, policies, authorization and authentication works.

You can find it here: ASP.NET Core Authorization with Barr Dorrans