When trying to connect with the access token is not allowing it. I've the following permissions. Permissions for the access token:

Login on SharePoint Online on a specific site URL
Version SharePointPnPPowerShellOnline 3.11.1907.0 - I cannot connect to the SharePoint with the Access token
Version SharePointPnPPowerShellOnline 3.8.1904.0 - I can connect to the site with the Access token but I cannot connect to the desired URL
3.11.1907.0
Connect-PnPOnline -AccessToken $a
3.8.1904.0
Connect-PnPOnline -AccessToken $a -Url https://contoso.sharepoint.com/sites/demo1
Get-PnPContext # To check the current URL
(you can retrieve this by executing Get-Module -Name *pnppowershell* -ListAvailable)
Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.
I just ran into the same problem. If the access token contains an audience, which is does by default, it will always connect to that URL instead of the Url provided.
Here's the problem:
https://github.com/SharePoint/PnP-PowerShell/blob/83ad7e82ff2bd3fb5cfdf3b844e87906ae221334/Commands/Base/ConnectOnline.cs#L600-L607
A solution would be to use the audience only when Url is null or empty.
Is there any update on this issue?
My use case is directly affected as I am (slowly) helping a team migrate their "traditional" Powershell to run inside an Azure Function that uses a Managed Identity for the bearer token (hence no need to maintain any credentials anywhere).
Right now we cannot really use PnP with a bearer token as all we ever get is a connection to the root site.
Any update on this one?
Need to be able to use a token to connect to other sites. This is blocking us moving from using service accounts to using principals.
I believe this is now fixed https://github.com/SharePoint/PnP-PowerShell/releases/tag/3.18.2002.0
Still an issue in 3.20.2004.0.
Using Fiddler, I tracked the difference between:
_Connect-PnPOnline <-clientId> <-certificate> <-tenant> <-url>_
and
_Connect-PnPOnline <-AccessToken> <-url>_
_Get-PnPSite_ calls _/sites.asmx_. In the first example, PnP passes the access token obtained from AzureAD via the Graph MSAL. In the second case, I pass the very same access token to the AccessToken parameter, but the bearer in the Authentication header for the _/sites.asmx_ call is different.
The end result is an invalid issuer due to the JWT having a different signature.
HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/10.0
x-ms-diagnostics: 3000006;reason="Token contains invalid signature.";category="invalid_client"
SPRequestGuid: 8cd14f9f-001c-9000-8a8e-6a482fe646c4
request-id: 8cd14f9f-001c-9000-8a8e-6a482fe646c4
MS-CV: n0/RjBwAAJCKjmpIL+ZGxA.0
Strict-Transport-Security: max-age=31536000
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 18
SPIisLatency: 20
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 16.0.0.20022
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
WWW-Authenticate: Bearer realm="027e0e2f-0ed0-43f3-920d-19b303e97e07",client_id="00000003-0000-0ff1-ce00-000000000000",trusted_issuers="00000001-0000-0000-c000-000000000000@,D3776938-3DBA-481F-A652-4BEDFCAB7CD8@,https://sts.windows.net/*/,00000003-0000-0ff1-ce00-000000000000@90140122-8516-11e1-8eff-49304924019b",authorization_uri="https://login.windows.net/common/oauth2/authorize"
Date: Wed, 06 May 2020 16:57:40 GMT
Content-Length: 52
{"error_description":"Invalid issuer or signature."}
Most helpful comment
I just ran into the same problem. If the access token contains an audience, which is does by default, it will always connect to that URL instead of the Url provided.
Here's the problem:
https://github.com/SharePoint/PnP-PowerShell/blob/83ad7e82ff2bd3fb5cfdf3b844e87906ae221334/Commands/Base/ConnectOnline.cs#L600-L607
A solution would be to use the audience only when Url is null or empty.