[SOLVED] Microsoft Graph API - Send Emails always return response code 403 with error text "Access is denied. Check credentials and try again."

Microsoft Graph API - Send Emails always return response code 403 with error text "Access is denied. Check credentials and try again."

We have implemented sending emails via graph api.

In microsoft app https://apps.dev.microsoft.com we have created application and for this application set permission 'Mail.Send'.

For authentication we are using way "Get access without a user".

We are receiving token via this url: https://login.microsoftonline.com/our_tenant/oauth2/v2.0/token and body is looks like this:

"client_id=app_id&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default&client_secret=app_secret_key&grant_type=client_credentials"

Mail is sent using this link:

https://graph.microsoft.com/v1.0/users/user_Email/sendMail

In body json with email Object.

When we sent email via this method then receive response code '403' with text "Access is denied. Check credentials and try again."

Before testing it we have created trial account for developed this integration. And with trial account this process have worked perfect.
Could you please help with current problem? Maybe we have forgotten something or have problem with account.

Best regards

Solution

Whenever you have a problem like this, where you have a token and you believe you SHOULD have access to something, but the API returns 403, the first step should be to parse the access token. You can use https://jwt.io for this, (or any other JWT parser). You want to confirm the following:

The aud claim is set to https://graph.microsoft.com
The tid claim is a GUID that matches the tenant ID of your Office 365 tenant
For app-only token (or as you call it, "get access without a user"): The roles claim is an array of the scopes you expect. In your case, it should include Mail.Send
For delegated access tokens (not your case, but included here for completeness): The scp claim is a string that contains the scopes you expect.

My guess here is that you may have a token with no roles claim at all, which is what will happen if an administrator has not provided consent. You can fix that by checking out this section of the Azure article on client credential flow.