Application vs. delegated OAuth permissions on Microsoft 365

OAuth apps are restricted in what they can do by the permissions they are granted. An app will ask for permissions on install - like Mail.Read, Calendar.Read, Files.ReadWrite - and, if the user consents, the app is then allowed to do actions within those permissions.

Microsoft 365 has two types of OAuth permissions: application permissions and delegated permissions. They often have similar or even identical names, but the difference is very important.

Delegated permissions grant the app access as that user within the confines of the permissions requested. For example, an app that has been granted the delegated permission Mail.Read can read the mail of the user who consented to the app. Delegated access is still bound by the access that user has. For example, an app that has been granted the delegated permission Files.Read can only read the same files as the user who consented.

Application permissions grant tenant-wide access to the permission requested. For example, an app that has been granted the application permissions Mail.Read and Files.Read.All can read all user mail and read all files. For obvious reasons, application permissions can only be granted by an admin.

For delegated permissions, admins can also consent on behalf of the organisation, meaning users don’t need to go through a further consent screen when they want to use an app.

Microsoft maintains a full reference of OAuth permissions so check it out if you’re not sure what one means. More information on application and delegated permissions can be found on the Microsoft website.