I have a daemon script that needs to access my Office 365 inbox to read messages. Currently I am using basic authentication with V1.0 of the Outlook Rest API, which works well but since it is being discontinued I am looking to move to the Graph API and OAuth 2.0 authentication. The client credentails flow, as described here seems to be the best option for a daemon script, however, I'm confused on the scope of the permissions that the app will have. The article I linked above makes it look as if the app will have access to the entire organization but I only need the script to be able to access my own account. I don't want my app to have access to other users' accounts and I don't think our I.T. department would allow that either.
So, what is the scope of the app's permission when using client-credentials authentication? If the answer is "the whole organization", then is there a way to limit the permissions to just my account? If not, what are my other options?
Edit: A similar question was asked here but did not get any answers.
That is correct. If you use Client Credentials, you are by definition using Application Scopes. These tokens have no "user" context and are therefore tenant-wide permissions. This is why Application Scopes always require Admin Consent before they can be used.
From the documentation:
Mail.Read (Read mail in all mailboxes)
Allows the app to read mail in all mailboxes without a signed-in user.
If this is just for your mailbox rather than something you're deploying to others, you can use the Authorization Code Grant with the offline_access
scope to obtain both an access_token
and refresh_token
.
Once you've "seeded" your app with the token, the app can use the refresh_token
to obtain a new access_token
when it expires. You may occasionally need to re-seed your app/service (for example, if your password changes) but otherwise, it should work without interaction.
It is now possible to scope application permissions according to Microsoft Docs.
Some apps call Microsoft Graph using their own identity and not on behalf of a user. These are usually background services or daemon apps that run on a server without the presence of a signed-in user. These apps make use of OAuth 2.0 client credentials grant flow to authenticate and are configured with application permissions, which enable such apps to access all mailboxes in a organization on Exchange Online. For example, the Mail.Read application permission allows apps to read mail in all mailboxes without a signed-in user.
Administrators who want to limit the app access to a specific set of mailboxes can use the New-ApplicationAccessPolicy PowerShell cmdlet to configure access control.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With