5

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.

Marc LaFleur
  • 31,987
  • 4
  • 37
  • 63
BigGerman
  • 525
  • 3
  • 11

2 Answers2

6

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.

Marc LaFleur
  • 31,987
  • 4
  • 37
  • 63
  • 1
    Marc - thanks a lot for your answer, I'm currently testing this. One question: does the refresh token expire based on time or only when there are changes to the account or app settings? All the documentation seems to just say that refresh tokens "can be used to retain access to resources for extended periods of time". – BigGerman May 11 '18 at 14:09
  • 2
    There are a few reasons why it might expire. The most common are password changes or the permissions getting revoked by the user or an admin. They can also be set to expire after a set time by the AAD admin. By default, however, they're expiration is set to `Until-Revoked` which means they'll remain active until they are revoked by the user, admin or a password reset. – Marc LaFleur May 11 '18 at 15:10
1

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.

Pascal R.
  • 2,024
  • 1
  • 21
  • 35