Here you can find the transcript of Episode #128 of PiaSys TechBites.

Welcome back to PiaSys Tech Bites. Today I want to talk with you about resource specific consent, which is a topic that makes me really, really excited. First of all, let me set the context. In Azure Active Directory and Microsoft Graph, we can register applications which can access the target workloads of Microsoft 365, eventually using application only access tokens.

When we do that, the applications that we can grant are, for example, permissions like Sites.Read.All, Sites.FullControl.All, Group.Read or ReadWrite.All where the All word means that we are granting a permission to access all of the resources in the target workload, using an application only access token.

In order to grant those permissions, we need at least for Microsoft Graph, a global tenant administrator user. This is a very strong requirement. The customers usually don’t like these requirement, and they don’t like to grant a permission to access all of the resources in a target workload of Microsoft 365 just for the sake of enabling, for example, an application to access a specific site collection.

It would be great, on the contrary, to being able to grant those permissions, specifying the target resource that we want to consent access to, and it would be also nice to be able to do this grant of the resource specific consent using a non-global administrator account.

Well, Microsoft in Microsoft Graph recently introduced the resource specific consent capability, which allows us to grant resource specific consent permissions in Microsoft 365 for Microsoft Teams. Specifically, a team owner, so not anymore a tenant global administrator, can grant permissions to an app, and the app will be granted permissions to access the resources in the team that the owner owns.

We don’t need anymore a global tenant administrator and the grant will be for a specific resource, the team that the owner owns. This capability works for app-only permissions-only and requires the Microsoft Teams UI in order to grant those permissions. We cannot use the Azure Active Directory portal UI to do this kind of grant.

Hopefully, that’s my hope, and let me say, please, please, please, to Microsoft, this capability will become available, not only for Microsoft Teams, but might be in the future also for other workloads. For example, SharePoint online. Making it possible to make a grant for a specific permission, targeting a specific site collection rather than all the site collections in the target tenant. Did I say please? I think so. Microsoft, please make it happen because all of the customers really, really need this capability, really need the resource specific consent for all of the workloads in Microsoft 365 and not only for Microsoft Teams.

Here, you can see what the permissions are nowadays for Microsoft Teams, and as you can see, you have permissions to manage the team or just to read the team settings. You have permissions to manage the channels, the tabs, the apps and the users. Plenty of capabilities that you can assign as a resource specific consent to apps registered in a specific target team in Microsoft Teams.

Like always, let me move to the demo environment and let me show you how to play with this new capability. In order to leverage the resource specific consent capability, we need first of all to register an application in Azure Active Directory, and the application will not have any specific permission as you can see right here in the API permissions page. We simply don’t have any permission. It is configured for application only. Right here, I’m using a client secret, but you could use also an X509 certificate if you like.

Once we have done that, we need to create a Teams application, which I did using the Yo teams generator, and we need to configure in the Manifest a new section called web application info, in which you need to declare the client ID of the application registered in Azure AD. The resource, which is just a string, which can be whatever you like right now. There is no constraint or requirement for specific content in this field, and then you have to register the permissions that you want to have for your application. The resource specific consent will target these permissions. I already created a package for this application, so I can go to Microsoft Teams and they can show you how it will behave in the UI when an owner will upload this app package in the target team. Here I am, I have a Test RST team in my Microsoft Teams.

I can go to manage team, apps and with sideloading enabled, I can upload the package of my custom app, which will include, the app Manifest. As you can see here, we see in the UI that app is requiring this long list of permissions, because I granted basically all of the permissions that we can grant to an app with a resource specific consent approach.

Here as an owner of the team, I can add the application, and by adding the application, I will also grant those permissions to the application. So let’s do that. My application is now added to the target team, and in a matter of a few seconds, I will be able to use a tool like the graph explorer to get information about the permissions granted to all of the apps are registered specifically, just one application in my scenario, in my target team. In order to do that, I can make a query for the target group backing my team, and specifically using the beta endpoint of Microsoft Graph, I can make a request under beta, as you can see for the permission grants in my targeted team. If I run this query, we can see that we have for our application, this is the client ID of our application registered in Azure Active Directory

We have all of the permissions that we granted, so channel create group, channel delete group and so on, and so forth all of the permissions declared that in the Manifest. Now that we have done that, we can play with a tool like for example, Postman, to use the granted permissions and to access the target resources. First of all, I will have to make a request to get an access token, so let me send the request and I will get back an access token, and we can see using, for example, jwt.ms, that this access token is just an application only access token. Here, we can see which will target Microsoft graph for the application that we registered in Azure Active Directory, but we don’t have any specific scope because this access token is for resource specific consent. Then, still using Postman we can play.

We can, for example, get the information about the team in order to do that. We need first of all, to get the access token as the actual value of a variable in our test file, so let me go here and let me copy the value of the access token in the appContextToken variable, so that by making a request to get the information about the team, using the beta endpoint of Microsoft Graph, I will be able to get the information about my team as well as I will be able to get information about the channels and everything else. As you can see here, I can access all of the information about the team that I’ve been consented to, but what if I change the group ID? So for example, what if I target in other team? Like for example, the one we see here, the Teams Provisioning team, well, let’s do that.

Let’s try to use a different group ID, so let me go back to the variables and let me change the team group ID that I want to target, so the current value will be this new team. If I make the same request, now I will get an exception because I’m not allowed to make such a query targeting a different group and a different team, so it works like charm, and as such, you can see that we have a resource specific consent for a specific team that the owner granted to our application. Like always I hope you found this topic interesting and I’m really looking forward to seeing you next week. Remember, subscribe to this channel. Thank you.