Request ms-graph token with scope "calendars.read"

[lawrencegripper]

Describe the bug

Command Name
az account get-access-token

Errors:

When using --resource-type ms-graph or --resource directly to get a token for MS Graph the token generated has limitted scopes to perform actions in the Graph API and the user isn't able to consent to additional scopes (or I couldn't find out how to).

For example trying:

az account get-access-token --resource https://graph.microsoft.com/calendars.read

Results in the following error:

Get Token request returned http error: 400 and server response:

{"error":"invalid_resource","error_description":"AADSTS500011: The resource principal named https://graph.microsoft.com/calendars.read was not found in the tenant named <TENANT_HERE>. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant.\r\nTrace ID: 232ea8dd-e957-40f2-9332-942ff1ae7200\r\nCorrelation ID: de7a27ab-cece-48bc-b2ee-17149ad5efcc\r\nTimestamp: 2020-04-13 12:28:47Z",
"error_codes":[500011],"timestamp":"2020-04-13 12:28:47Z",
"trace_id":"232ea8dd-e957-40f2-9332-942ff1ae7200",
"correlation_id":"de7a27ab-cece-48bc-b2ee-17149ad5efcc",
"error_uri":"https://login.microsoftonline.com/error?code=500011"
}

Alternatively if you do az account get-access-token --resource-type ms-graph then attempt to use the token to retrieve calendar information with:

TOKEN=$(az account get-access-token --resource-type ms-graph  | jq -r .accessToken)
curl "https://graph.microsoft.com/beta/me/calendar/calendarView?startDateTime=2019-01-01T19:00:00&endDateTime=2019-01-01T19:00:00" -H "Authorization: Bearer $TOKEN"

Returns:

{"error":
{"code":"ErrorAccessDenied",
"message":"Access is denied. Check credentials and try again."
}}

While curl "https://graph.microsoft.com/v1.0/me" -H "Authorization: Bearer $TOKEN" will work.

Looking at the JWT content for the token generated the scopes are as follows:

"scp":"AuditLog.Read.All Directory.AccessAsUser.All Group.ReadWrite.All User.ReadWrite.All"

How can I go about generating a token with additional scopes like calendars.read?

Attempting to do UserConsent flow with something like this (AzureCLI ClientID):

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F&response_mode=query&scope=user.read%20mail.read&state=12345

Fails with:

AADSTS65002: Consent between first party applications and resources must be configured via preauthorization. Visit https://identitydocs.azurewebsites.net/static/aad/preauthorization.html for details

To Reproduce:

Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

• Put any pre-requisite steps here...

TOKEN=$(az account get-access-token --resource-type ms-graph  | jq -r .accessToken)
curl "https://graph.microsoft.com/beta/me/calendar/calendarView?startDateTime=2019-01-01T19:00:00&endDateTime=2019-01-01T19:00:00" -H "Authorization: Bearer $TOKEN"

Expected Behavior

A way to generate a token for user selected scopes, for example to allow calendar information is printed for the user.

In terms of implementation, when requesting a scope which needs consent a dialog/browser could be displayed for the user to consent similar to signin experience.

Environment Summary

Linux-5.3.0-46-generic-x86_64-with-debian-buster-sid
Python 3.6.5
Installer: DEB

azure-cli 2.3.1

Extensions:
resource-graph 1.0.0
interactive 0.4.1
aks-preview 0.4.19

Additional Context

[yonzhan]

add to S169

[yonzhan]

add to S171

[jiasli]

Currently Azure CLI still uses ADAL to authenticate. The first step of authorization code flow is /authorize:

https://login.microsoftonline.com/common/oauth2/authorize?
response_type=code
&client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46
&redirect_uri=http://localhost:8401
&state=5a82wah3vyc2iy1hxdb6
&resource=https://management.core.windows.net/
&prompt=select_account

So, az account get-access-token won't work for https://graph.microsoft.com/calendars.read which requires MSAL authentication.

Even with our current on-going MSAL migration work, the first step is /authorize:

https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?
client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46
&response_type=code
&redirect_uri=http://localhost:8400
&scope=https://management.core.windows.net//.default+offline_access+openid+profile
&state=1aec1b58-74da-4fbe-9dca-7bb31b4733b6
&prompt=select_account

According to Microsoft identity platform and OAuth 2.0 authorization code flow,

scope:
A space-separated list of scopes. The scopes requested in this leg must be equivalent to or a subset of the scopes requested in the first leg.

So the initial /authorize must have scope=https://graph.microsoft.com/calendars.read. But when I tested using scope=https://graph.microsoft.com/calendars.read with /authorize:

https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46
&response_type=code
&redirect_uri=http://localhost:8400
&scope=https://graph.microsoft.com/calendars.read+offline_access+openid+profile
&state=77e76d22-16ec-42c1-a37f-af70fb069bbf
&prompt=select_account

I got the same error:

http://localhost:8400/?
error=invalid_request
&error_description=AADSTS65002: Consent between first party application '04b07795-8ddb-461a-bbee-02f9e1bf7b46' and first party resource '00000003-0000-0000-c000-000000000000' must be configured via preauthorization. Visit https://identitydocs.azurewebsites.net/static/aad/preauthorization.html for details
Trace ID: b1f7e1e6-e01b-4433-8840-1c07c93e0e00
Correlation ID: 9b8a80a7-b2c6-4a47-ae03-6d8d1f66022e
Timestamp: 2020-06-15 07:18:07Z
&error_uri=https://login.microsoftonline.com/error?code=65002
&state=77e76d22-16ec-42c1-a37f-af70fb069bbf

I think it is because Azure CLI is not authorized in the first-party app portal to access scopes like calendars.read. Let me confirm with our PM whether we can/need apply for such permissions.

[jiasli]

Currently without absolute needs, we don't want to extend Azure CLI's pre-authorized permissions.

We are considering supporting custom client ID in #22775.

A workaround is to create and use your own service principal which has such permissions (#22775 (comment)).