Reputation: 754
In this topic, the author explains how to get an access token based on users login and password, skipping the authorization dialog.
I could hit the endpoint and get an access token, and refresh token:
GET https://login.microsoftonline.com/348a...6e4/oauth2/token?grant_type=password&\
client_id=6d5f...64f&client_secret=g...f2&[email protected]&\
password=P@ssW0RD&resource=https://graph.microsoft.com/&\
scope=user.read%20calendars.read%20MailboxSettings.Read%20Mail.read%20Mail.Send
//RESPONSE
{
"token_type": "Bearer",
"scope": "User.Read",
"expires_in": "3600",
"ext_expires_in": "3600",
"expires_on": "1559602338",
"not_before": "1559598438",
"resource": "https://graph.microsoft.com/",
"access_token": "eyJ0eXAiOiJKV...KJmNhyz5bvhzCWiFA",
"refresh_token": "AQABAAA...VkgAA",
"id_token": "eyJ0...xLjAifQ."
}
But when I tried to get the user´s email, I get an error:
GET https://graph.microsoft.com/v1.0/me/messages?\
$select=sender,subject,ReceivedDateTime&\
$filter=ReceivedDateTime%20ge%202019-05-01&$top=20
RESPONSE
{
"error": {
"code": "ErrorAccessDenied",
"message": "Access is denied. Check credentials and try again.",
"innerError": {
"request-id": "e35f...94",
"date": "2019-06-03T21:39:40"
}
}
}
Is this authentication method still valid to Microsoft Graph API? If not, Is there any another way to get the user authorization using only login and password, without any user interaction, just getting his login and password?
Upvotes: 1
Views: 279
Reputation: 33094
You cannot dynamically specify scope
with the v1 Endpoint. That model is on only supported with the newer v2 Endpoint (see Scopes, not Resources in the documentation).
In order access the user's mailbox, you'll need to add Mail.Read
to your application's registration in the Azure Portal.
Keep in mind that you'll either need an Admin to consent to your application for all users in the tenant or have each user sign-in interactively at least once so they can consent themselves.
I'd also be remiss if I didn't point out that using the Password grant is almost always a bad idea. It is fundamentally less secure than every other OAuth Grant.
Upvotes: 1