One thing related to OAuth 2.0 and JWTs that's still a bit confusing is 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.
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.
You don't necessarily need OAuth2 scopes, and you can handle authentication and authorization however you want. But OAuth2 with scopes can be nicely integrated into your API (with OpenAPI) and your API docs.
not add roles to your JWT and fetch them on demand if (a) you want to prevent any time windows in which a person has rights assigned he shouldn't have or (b) avoid the overhead of a blacklist or (c) avoid increasing the size of your JWT payload to increase slightly and (d) if you accept that this comes at the cost of ...
OAuth 2.0 scopes provide a way to limit the amount of access that is granted to an access token. For example, an access token issued to a client app may be granted READ and WRITE access to protected resources, or just READ access. You can implement your APIs to enforce any scope or combination of scopes you wish.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With