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