Sharing Microsoft Graph permissions and solution Azure App Registrations

This article looks at using Microsoft Graph permissions in Azure App registrations and whether you should use Graph in specific Azure App registrations types and if it is ok to expose these with other scopes and roles. Is it ok to expose Graph permissions in public Azure App registrations?

Using Graph with public applications

As a rule, I do not allow any Graph permissions to be assigned to an Azure App registration used by a public application apart from the delegated User.Read permission or others like this. The problem with sharing a Graph permission in this way is that you allow the full permission to be shared and not just the specific use case from your application. For example, if I expose the User.ReadWrite.All permission in a public Azure App registration, anyone who acquires an access token for this permission can do everything allowed. My application might only need to allow a user to update the firstname, lastname properties. With this token, I could list out all users on this tenant and share this in an unfriendly way or create and delete users.

If you find a public Azure App registration and Graph permissions other than the User.Read scope, you probably have found a security attack possibility or evaluated permissions problem.

A better setup is to separate the Graph permissions into a different Azure App registration and only allow this to be used in a confidential client.

Using Graph with application App Registrations

When using Graph application permissions, I create a specific Azure App registration to expose the permissions which require a secret or certificate to acquire the access token. You should not share this with an Azure App registration used to expose different APIs. If only using this inside a specific confidential Web client which is not used to expose further APIs, then it is ok to share the Graph permissions and the confidential client definitions in the same Azure App registration.

I never mix application permissions and delegated permissions in the same Azure App registration. If you find yourself doing this, it is probably the result of an architecture error and should be reviewed.

Separating Graph permissions and solution App registrations

When using an Azure App registration to use an specific API role or scope, do not use the same one to expose a Graph permission. This is because the intent of the Azure App registration is to do whatever is allowed in the API exposed using this. If you also allow Graph permissions, the App registrations can be used for two different intentions. The client using this could execute an evaluated privilege attack as the same secret/certificate can be used to acquire both of the permissions or even worse, no secret at all is required to get an access token for the Graph API.

You might not want to allow the client using the API to have the full access to everything exposed with the Graph permission. You probably only want to expose a subset. This can be solved by using an API which validates the specific request and in a trusted environment and the Graph permissions from a separate Azure App registration can be used with a confidential client and only the subset of the Graph features are exposed to the third party. A secret or certificate must be required to get the access token for the Graph permission. It it not possible for the third party application to get an access token for the Graph permission.

What about sharing Graph permissions and third party applications

Shared Graph permissions to third party clients is sharing trust. I would avoid this as much as possible and use a zero trust strategy. Only expose or share what is required. How secure are the secrets or certificates in the other solutions? How easy is it to rotate the secrets?