5

I'm quite well versed with most things related to OAuth 2.0 and JWTs, but one thing that's still a bit confusing is if/when to use scopes vs. roles.

I think some of the confusion is coming from how role-based authorization works in ASP.NET Core (which is the primary language/framework at my workplace). For example; if I have roles in my JWT as follows

{
  "aud": "test",
  "iss": "http://localhost:8080/auth/realms/test/",
  "iat": 1585192274,
  "nbf": 1585192274,
  "exp": 1585196174,
  "sub": "12345",
  "roles": ["Admin", "SuperUser"]
}

I can protect routes quite easily without having to do much e.g:

[ApiController]
[Route("api/v{version:apiVersion}/template/test")]
public class TestController : Controller
{
    [HttpGet]
    [Authorize(Roles = "Admin")]
    public IActionResult Get()
    {
        return Ok("test");
    }
}

I could implement something very similar to the above using scopes with dotnet authorization policies, but I'd just like to know if there's some guidance about if/when to use scope or roles, or is it simply a matter of preference...

I can't find much reference to the roles claim in any of the OAuth/JWT-related RFCs, whereas scopes are mentioned throughout.

Ryan.Bartsch
  • 1,550
  • 11
  • 29

1 Answers1

10

The most significant difference between scopes and roles/groups is who determines what the client is allowed to do.

Resource scopes are granted by the resource owner (the user) to an application through the consent screen. For example, the client application can post to my timeline or see my friends list.

User roles and groups are assigned by an administrator of the Azure AD directory. For example, the user can submit expense reports or the user can approve expense reports.

Scopes are typically used when an external application wants to gain access to the user's data via an exposed API. They determine what the client application can do.

Role- or group based access is typically used within an application to determine what a user can do.

MvdD
  • 17,926
  • 5
  • 51
  • 83