Get-AzAccessToken should also allow specifying scopes

[petehauge]

Description of the new feature

The Get-AzAccessToken commandlet is awesome! Unfortunately I can't use it for my scenario because it's missing being able to set the "Scopes" in the authentication flow.

The feature request would be to enable passing scopes to the commandlet and could be done in two different ways:

Add -Scope as a parameter:
Get-AzAccessToken -ResourceUrl "https://graph.microsoft.com" -Scope "Directory.readwrite.all"

Enable Resource URL to include scopes:
Get-AzAccessToken -ResourceUrl "https://graph.microsoft.com//Directory.readwrite.all"

Scenario

I wanted to mention the scenario in which I want to use this feature: I am using the MicrosoftTeams PowerShell module (currently in preview). There is something supported by the API that's not yet supported by the module, so for 1 particular scenario, Adding tabs to an existing teams channel, I need to call the Rest API instead of a commandlet. The code looks like the following, but the Access Token part is the only bit of the code that doesn't work.

# First, see if the Lab Services Team app is already installed
$labServicesTeamsApp = Get-TeamsAppInstallation -TeamId $groupId -AppId $labServicesTeamsAppId
if (-not $labServicesTeamsApp) {
    Add-TeamsAppInstallation -TeamId $groupId -AppId $labServicesTeamsAppId
}

# Config file doesn't currently have tab name, should we add it?  Just assuming "General" tab for now
$tabDisplayName = "General"
$channel = Get-TeamChannel -GroupId $groupId | Where-Object {$_.DisplayName -ieq $tabDisplayName}

# -------------------------------------------------------------
# Code to add the app to the tab in the team
$apiUrl = "https://graph.microsoft.com/v1.0/teams/$groupId/channels/$($channel.Id)/tabs"

$apiBody = @"
{
    "displayName": "Azure Lab Services",
    "teamsApp@odata.bind" : "https://graph.microsoft.com/v1.0/appCatalogs/teamsApps/$labServicesTeamsAppId",
      "configuration": {
        "entityId": "AzureLabs",
        "contentUrl" : "https://labs.azure.com/subscriptions/$subscriptionId/resourcegroups/$resourceGroupName/providers/microsoft.labservices/labaccounts/$labAccountName/labs?host=Teams",
        "removeUrl" : "",
        "websiteUrl" : "https://labs.azure.com/subscriptions/$subscriptionId/resourcegroups/$resourceGroupName/providers/microsoft.labservices/labaccounts/$labAccountName/labs?referrer=Teams&tenantId=$tenantId&groupId=$groupId"
    }
}
"@

# Need TeamsTab.ReadWrite.All scope for this token
# TODO:  This line of code doesn't work - access token doesn't have the right scopes!
$accessToken = (Get-AzAccessToken -ResourceUrl "https://graph.microsoft.com").Token

$tabdetails = Invoke-RestMethod -Headers @{Authorization = "Bearer $accessToken"} `
                                    -Uri $apiUrl `
                                    -ContentType 'application/json' `
                                    -Method POST `
                                    -Body $apiBody -Verbose


$generaltabdetails = Invoke-RestMethod -Headers @{Authorization = "Bearer $accessToken"} `
                                    -Uri $apiUrl `
                                    -ContentType 'application/json' `
                                    -Method GET

[dingmeng-xue]

We will evaluate this feature request.

[thalluripk]

Any progress on this?

[HMassi87]

@dingmeng-xue I can see that this moved to "Breaking Change Release" about 5 months ago, does this means that it will be included in the next release?
This would be a game changer for a lot of automations where people are trying to avoid App Secrets

[dingmeng-xue]

@HMassi87 , that label means feature will introduce breaking change potentially. We haven't planned it because we are still understanding the benefit to users and potential impact.

Back to original requirement, Get-AzAccessToken and Invoke-AzRestMethod both have already supported resource id of MSGraph. Scope seems not required because MSGraph only granted high privileged delegate role to Azure PowerShell. It means client should not/cannot do more than signed in account.

[HMassi87]

@dingmeng-xue
Thanks for the quick reply! I think that the biggest problem most of us are finding with this approach is that we can't use this module to authenticate and gain the same level of access that we have on Graph explorer for example.

I can't do anything on Intune using managed identities
I use this code for example to authenticate either with the local account or with the managed identity depending on where I am running it

if(!$Global:AZConnection){
    try{
        if($nonInteractive){
            Write-Output "Logging in with MI"
            $Null = Connect-AzAccount -Identity -ErrorAction Stop
            Write-Output "Logged in as MI"
        }else{
            Write-Output "Logging in to Azure AD"
            $Global:AZConnection = Connect-AzAccount -ErrorAction Stop
            Write-Output "Logged in to Azure AD with $($Global:AZConnection.Context.Account.id)"
        }
    }catch{
        Throw $_
    }
}
$Token = (Get-AzAccessToken -ResourceUrl "https://graph.microsoft.com/").Token

But the only scopes that I get from this are
"scp": "AuditLog.Read.All Directory.AccessAsUser.All email openid profile"

I can even expose my API and create my own scopes and I am able to get a token for those scopes using something like
$MyGraphToken = Get-AzAccessToken -ResourceUrl "api://{API-GUID}"
but not for the MS Graph API scopes that I assigned to the API like DeviceManagementManagedDevices.Read.All or any other scope what forces me to create an App Secret although everything I need to do could be done using delegated permissions

[dingmeng-xue]

Hi @petehauge and @HMassi87 , After verifying the scope in my environment, I realized your requirement cannot meet even we changed the code. Please look into #18080.

Azure PowerShell is the first party app. For MSGraph API, All required permissions are granted by MSGraph in advance. AuditLog.Read.All Directory.AccessAsUser.All email openid profile are all granted. You cannot get Get-AzAccessToken -ResourceUrl "https://graph.microsoft.com/Directory.readwrite.all" if client id is Azure PowerShell.

Your requirement can be met when Azure PowerShell becomes 3rd party app. It is on our roadmap. I'm hesitating to merge the PR. What's your thought?

[petehauge]

Hi @dingmeng-xue - good question on this one, if it doesn't cover my original scenario that I'm not sure I can use it. I have a question though, based on your other comment (Azure Powershell becoming 3rd party app) - if that happens, does that mean that we will need your code in the PR 18080 anyway to enable the scenario? If so, seems like it's still worthwhile to merge? Thanks!

[dingmeng-xue]

Hi @dingmeng-xue - good question on this one, if it doesn't cover my original scenario that I'm not sure I can use it. I have a question though, based on your other comment (Azure Powershell becoming 3rd party app) - if that happens, does that mean that we will need your code in the PR 18080 anyway to enable the scenario? If so, seems like it's still worthwhile to merge? Thanks!

Scope contains 2 parts, resourceId and permission. Azure PowerShell accepts any resource id and automatically appends permission .default. It creates wrong scope when user specifies permission as part of resource id. This change is required.

MSAL accepts array of scopes during authentication. So you can see strict syntax should be

Get-AzAccessToken -Scope <string[]>

or

Get-AzAccessToken -ResourceUrl <string> [-Permission <string[]>]

Support above requires lots of code change because existing code is not designed for multiple scopes/permissions. If user cannot get benefit immediately, I'd like put it on hold for a while.

[petehauge]

I see, thanks @dingmeng-xue - my original issue was accessing the Teams API (since I'm logged in against the same tenant) - but if that won't work with this change than I don't have a preference on merging since I can't use the work yet.

In particular, I want to be able to get an access token with the following scope:
TeamsTab.ReadWrite.All

Thanks!

[mabster]

I can't do anything on Intune using managed identities

@HMassi87 I think I'm having the same issue you are.

I've added two application scopes to my managed identity (Enterprise Application):

• DeviceManagementManagedDevices.Read.All
• DeviceManagementServiceConfig.ReadWrite.All

... yet when the App Service running as that managed identity calls Get-AzAccessToken, those two permissions do not appear as scopes. All the others I have added (e.g. Directory.Read.All, TeamMember.ReadWrite.All) appear, but not these two.

I know I'm risking drifting off topic, but is there something about the Intune Graph endpoints that's making this happen? )Feel free to hit me up on Twitter (@mabster) if you'd prefer to take the conversation out of GitHub.)

If adding a -Scope parameter to Get-AzAccessToken could solve this issue and somehow force those scopes into the token, that would be awesome.

[mabster]

OK project owners, now I'm really confused.

On Friday I disabled all the scheduled jobs in my Azure App Service that are calling Get-AzAccessToken and left the service idling over the weekend.

This morning, Get-AzAccessToken does indeed return a token with the scopes I had added to my managed identity last week.

Does Get-AzAccessToken cache somehow? Why was it not returning these new scopes as soon as I added them to the MSI? Is it using a refresh token to keep the current (now incomplete) token "current" somehow?

[dingmeng-xue]

@mabster , you are right that there is a kinds of cache. After login (access token login), client will get primary refresh token and protect it leveraging MSAL (the secret of SP is not the case). The expiration of primary refresh token is 90 days. Get-AzAccessToken redeem access token to specific endpoint (ARM by default) using refresh token.

Azure PowerShell use .default as permission. But whole logic is controlled by AzureAD and MSAL. I cannot confirm that your case is a bug or by design. If you have concern, please create a new Github issue and share us your steps.

[JustinGrote]

Out of curiosity, the Graph API "default" application supports adding dynamic scopes that aren't part of the original specification with admin approval. Maybe similar could be added for connect-azaccount -scopes?

[dingmeng-xue]

@JustinGrote @mabster ,

When Connect-AzAccount on behalf a user, user cannot see "approval required" or "permission request" page because Azure PowerShell is the first party app and different from the third party app such as MSGraph PowerShell module. For MSGraph features, as third party app, msgraph module can gradually get consent from user. However, as first party app, Azure PowerShell doesn't support gradual consent. It has Directory.AccessAsUser.All permission which means "Allows the app to have the same access to information in the directory as the signed-in user." It's impossible to get an access token which has limited permission. In addition, user cannot use Azure PowerShell to access API which requires high privileged permission not covered by Directory.AccessAsUser.All.

When Connect-AzAccount as an app without user, the authentication flow is https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow. When client gets token, "the value passed for the scope parameter in this request should be the identifier (app ID URI) of the resource you want, affixed with the .default". "This value informs the Microsoft identity platform endpoint to include in the access token all the app-level permissions the admin has consented to." It seems client cannot return an access token with partial permissions.

Please let me know if you have further question.

[JustinGrote]

@dingmeng-xue thank you for taking your valuable time for a detailed explanation, it is appreciated, and I hope others find it useful as well.

[dingmeng-xue]

This feature will be discussed again when Azure PowerShell can work using the 3rd party app id. Closing this request now. Your thought is welcome.

[ghost]

Hi, we're sending this friendly reminder because we haven't heard back from you in a while. We need more information about this issue to help address it. Please be sure to give us your input within the next 7 days. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!

[HMassi87]

My biggest problem at the moment is trying to use delegated permission, this can be achieved using the MSAL.PS module cmdlet get-msaltoken but would prefer to use the same module used to authenticate as the managed identify. This process would avoid the necessity to create an App Secret or use of certificates.

…

On Mon, 9 May 2022, 14:29 Dingmeng Xue, ***@***.***> wrote: Hi @petehauge <https://github.com/petehauge> and @HMassi87 <https://github.com/HMassi87> , After verifying the scope in my environment, I realized your requirement cannot meet even we changed the code. Please look into #18080 <#18080>. Azure PowerShell is the first party app. For MSGraph API, All required permissions are granted by MSGraph in advance. AuditLog.Read.All Directory.AccessAsUser.All email openid profile are all granted. You cannot get Get-AzAccessToken -ResourceUrl " https://graph.microsoft.com/Directory.readwrite.all" if client id is Azure PowerShell. Your requirement can be met when Azure PowerShell becomes 3rd party app. It is on our roadmap. I'm hesitating to merge the PR. What's your thought? — Reply to this email directly, view it on GitHub <#14085 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AYDKZG5E3YB22OLCJFEQ7WTVJEHJ5ANCNFSM4W5OJURA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ehrnst]

I found this thread when trying to request a specific app role from a custom app registration using MSI. If you assign the MSI multiple app roles, the token will always include all roles. This seems like a similar problem to the delegated scopes.

[StevieLamb]

This feature will be discussed again when Azure PowerShell can work using the 3rd party app id. Closing this request now. Your thought is welcome.

Hi @dingmeng-xue, I came to this thread through investigation of the same symptoms as the OP.

I just had 2 questions, and I'm hoping you will be able to answer?

1. when you say
   "...It has Directory.AccessAsUser.All permission which means "Allows the app to have the same access to information in the directory as the signed-in user...""
   am I correct in inferring that, if the executing user (MSI or interactive user) has high privileges, those will be the available permissions for subsequent access using the token?
2. regarding
   "This feature will be discussed again when Azure PowerShell can work using the 3rd party app id"
   Is the move of Azure PowerShell to a 3rd party app on the roadmap?

Many thanks

[dingmeng-xue]

@StevieLamb , For question #1, I cannot confirm MSI. My understanding is it is service account. About interactive user, you are right that access token has high privilege from user.

For question #2, let's ping @dcaro , @Alex-wdy , @isra-fel

[StevieLamb]

Really appreciate your response. And sorry: yes, MSI as in Managed Identity, which is now MSFT's preferred security principal for Azure Automation (the RunAs account alternative being deprecated imminently). Look forward to hearing more.

[dingmeng-xue]

About MSI, Azure doesn't recommend user to use its token in anywhere. So, it's not easy to get access token. You can just use normal service account. Create service principal, grant sufficient permission, login Azure PowerShell with that service principal, get access token, and use it.

[StevieLamb]

About MSI, Azure doesn't recommend user to use its token in anywhere. So, it's not easy to get access token. You can just use normal service account. Create service principal, grant sufficient permission, login Azure PowerShell with that service principal, get access token, and use it.

I've never encountered that recommendation; where is it documented please?
Edit: it appeared ot me - and many others, apparently - that the purpose of Get-AzAccessToken -ResourceType MSGraph was precisely this. It's superfluous in other contexts, such as directly acquiring a token via e.g. MSAL.PS

[dingmeng-xue]

Managed identity (MSI) links to an azure resource. If you use its token and execute script somewhere else, it is against the principle of MSI. But, definitely, you can use it for the time being.

[StevieLamb]

But, definitely, you can use it for the time being

This is good to know, thanks for confirming, @dingmeng-xue

Managed identity (MSI) links to an azure resource. If you use its token and execute script somewhere else, it is against the principle of MSI

This is still a little bit confusing to be honest, in terms of what is meant by "somewhere else".
Fortunately - based on the above - it may not be a pressing thing to understand!

But clarity would be good: for when the "for the time being" part of the above statement is no longer true, and particularly if that change is not well-publicised.
Please do feel free to redirect me if there's a more suitable person/team & location to continue this discussion?

The only use case I'm interested in is:

• using a system-assigned MSI within an Azure Automation account's Runbook
• accessing MSFT resources with that MSI, where authorisation is
  -- using Azure RBAC as far as possible, and
  -- using MS Graph API permissions where Azure RBAC is not an option (such as accessing anything within Microsoft 365)

In the main, the confusion is what MSFT intend that we should use for AuthN and AuthZ to Microsoft 365 resources.
If a RunAs account is deemed so insecure that the model is being deprecated, I'm finding it hard to understand how manually creating a service principal via e.g. an App Registration would be any better?

Authentication in both cases relies on either a client secret or certificate, and authorisation is assigned the same way - as far as I can tell! - i.e. using either the App Registration's API permissions tab in the Identity portal, or associated PowerShell. So any weaknesses inherent in using one would seem to apply to the other.

I do appreciate your time so far, thanks.
Little it saddened that we haven't heard from your colleagues about a roadmap item yet.

[dcaro]

@StevieLamb using a 3rd party app for Azure PowerShell has several consequences, one of them being that an admin would need to grant permission to the app. This would create a massive breaking change in the behavior of the client that would impact every organization using Azure PowerShell.
We regularly evaluate this change but so far, our assessment of the benefits vs risks is not in favor of making this change.