Roles and Scopes in Azure Identity
Roles manage User’s access and Scopes manage Application’s access.
Roles and Scopes are terms derived from OAuth.
These are important entities in Azure while working with access management.
Roles, we are all aware of, we use them everywhere for access management and Scopes are new for those who are not aware of OAuth.
In this article, we will talk about Roles and Scopes from Azure AD/B2C prospect.
The Role is a mechanism in OAuth 2.0 to limit user’s access to resources.
A resource can be an endpoint in REST or a link on UI. In Azure, we create roles by adding them to the application manifest file.
There are two types of roles.
- Application Role
- User Role
I have covered this in another article here.
The Scope is a mechanism in OAuth 2.0 to limit an application’s access to a user’s account.
The scope is, what an application can access on behalf of the user. In Azure, we create scopes by adding them to the application manifest file.
Let's try to understand with an example.
Assume, we have one API hosted in Azure API Management. The API is owned by an Insurance Company called SecureAssets. SecureAssets has insurance products covering property and casualty, accidents, and health.
property endpoints
- secureassets/properties/claims | Get all property claims
- secureassets/properties/claims/approve | approve a claim
- secureassets/properties/claims/reject | reject a claim
casualty endpoints
- secureassets/casualties/claims | Get all casualty claims
- secureassets/casualties/claims/approve | approve a claim
- secureassets/casualties/claims/reject | reject a claim
health endpoints
- secureassets/health/claims | Get all health claims
- secureassets/health/claims/approve | approve a claim
- secureassets/health/claims/reject | reject a claim
Now let’s assume there are three different teams in SecureAssets managing three different types of products. These all three teams have their own UI, the front-end application.
Let’s summarize our assumptions.
We have one company owning one single API, inside the company we have three different teams managing three different products and every team has its own UI front-end application (one API is being consumed by multiple client application)
Q 1: How do we ensure that if only the manager has access to approve or reject a claim?
Ans: Roles.
We can protect our API endpoints using roles against Users. First, we need to add roles into Azure AD applications (the backend application ) and then roles assignments. On the API side, we need to decorate our endpoints with Roles.
Q 2: How do we ensure that health front-end applications can only access health endpoints?
Ans: Scopes.
We can protect our API endpoints using scopes against Applications. We need to add scopes into the Azure AD application (the backend application ). Now while creating three different Client Applications, we need to add different scopes.
property, casualty, and health
- property application has property scope
- casualty application has casualty scope
- health application has health scope
On successful login, the client application asks for user consent. User consent means, application asking for user permissions to access data on behalf of the user.
Contoso Test App is asking for user permissions for scopes
- Read and write your files
- Read your calendar
- Sign you in and read profile
Thanks for reading, share your feedback in the comment section.
