If you haven't already, please check out Part 1 of this series where I discuss briefly what Apps Registrations and Enterprise Apps are.
In this article I will be discussing App Roles and Scopes. To me, this was quite confusing at first and I needed a lot of research and experience before I fully understood all the parts and how they fit together.
As I stated in Part 1, this subject is huge! For this article, even though I am focusing on just App Roles and Scopes, there is still way too much to cover and I am going to keep it fairly high level.
App Roles
App Roles are created on your App Registration and they are specific to that app. They are used to assign permissions within your app. For example, you could create an App Role named "Full Admin" which could do everything inside your app. Your app would need to have logic to read the token, read the Roles within, and grant the appropriate permissions inside the app.
To define App Roles in the Portal you must go to your App Registration, go to 'App Roles' in the menu, and then click on 'Create an app role'. When you create the App Role you get to decide what kinds of objects can be assigned to the App Role. The options are Users/Groups, Applications, or Both. These options will be discussed below.
Defining App Roles via the nice UI in the Azure Portal is actually fairly new. Prior to having the UI, you would have to manually update the code in your App Registration's 'Manifest' in order to add or update an App Role. Inside the Manifest, the App Roles are conveniently found under the 'appRoles' section.
Allowed Member Type: Users/Groups
Choosing this option allows you to assign AzureAD Users or Groups to your App Roles. Through the Portal, you actually do the assignment via the particular Enterprise App that is tied to the App Registration, under the 'Users and Groups' section. Note: to assign Groups using this method, you must have AzureAD Premium licenses.
Allowed Member Type: Applications
Choosing this option allows you to assign other apps to your App Roles. This is useful when apps need to talk with other apps using 'Application' Permissions. Application Permissions just means that App1 will use its own credentials to talk with App2. (in order to do app-to-app communication using 'Delegated' Permissions you must use Scopes, more on that below).
To assign another app to your App Role, you must go to the App Registration of the other app, go to 'API Permissions', choose 'Add a permission', pick 'My APIs', choose your app which contains the App Role, choose 'Application Permissions', and then finally choose the App Roles from the list.
In the resultant token, App Roles will show up under the 'roles' section.
Scopes
Scopes are useful when apps need to talk with other apps using 'Delegated' Permissions. This means if a user signs into App1, and App1 needs to talk with App2, then it will do so on behalf of the user. In other words, App1 will talk to App2 by using the credentials of the user who is signed into App1.
To define Scopes in the Portal you must go to your App Registration, go to 'Expose an API' in the menu, and then click on 'Add a scope'. If you were to update Scopes in your App Registration's Manifest, you would find them under then 'oauth2Permissions' section.
To assign another app to your Scope, you must go to the App Registration of the other app, go to 'API Permissions', choose 'Add a permission', pick 'My APIs', choose your app which contains the Scope, choose 'Delegated Permissions', and then finally choose the Scope from the list.
In the resultant token, Scopes will show under the 'scp' section.