70-533: Understanding Azure AD Permission Types
This is part of a series of posts I will be writing while studying for the 70-533 exam from Microsoft. You can see all of the posts related to this exam here.
While studying the “Managing Azure Identities” requirements for the Microsoft 70-533: Implementing Microsoft Azure Infrastructure Solutions exam, I came across the concept of permissions types. More specifically, there are two types of permissions: delegated and application. According to Microsoft, these permissions are described as follows:
“Delegated” permissions, which specify scope-based access using delegated authorization from the signed-in resource owner, are presented to the resource at run-time as “scp” claims in the client’s access token.
“Application” permissions, which specify role-based access using the client application’s credentials/identity, are presented to the resource at run-time as “roles” claims in the client’s access token.
I personally found this description to be a little terse for someone just coming into Azure AD. So here I thought I would try to distill what these permissions are and when they are used.
What It Means
Essentially, delegated permissions are when an application is given a subset of a user’s permissions. These subsets are called scopes. For example, the User.ReadBasic.All scope “Allows the app to read the basic profile of all users in the organization on behalf of the signed-in user.” Notice that the read happens under the context of the signed-in user. The final set of permissions are an intersection of all the scopes that are granted to the application.
The full set of scopes can be found here.
When it is Used
These permissions are generally used when a user will sign into an application. The application will be operating in the context of the user. The application will have the user permissions that have been specifically delegated to it.
Furthermore, these permissions are used when the client is considered public. According to OAuth documentation, applications are consider public when the clients are “incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.” This would be a native client (public) installed on a device, or a user-agent-based client (public) which runs in a device’s browser (source).
These roles will appear as “scp” claims in the token.
What It Means
Application permissions are when authentication and authorization is done in the context of the application itself, rather than the user executing the action.
When it is Used
These are used when you want to create a service account under which a particular application or service will be running.
These permissions are used when the client is considered confidential. The OAuth definition of confidential clients are clients “capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.”
Microsoft says that these are web clients, which are “a type of client application that executes all code on a web server, and able to function as a ‘confidential’ client by securely storing its credentials on the server.” An example of this would be a web server that makes API calls on the back-end to other services. In this case, the web server could use application permissions to make requests as itself.
These roles will appear as “role” claims in the token.
I hope this short article gives you a bit more insight into the permissions types. I hope this helps you on your journey to passing your 70-533 exam. Check out my additional posts about preparing for the 70-533 exam.