ExpertiseKnowledgeToolsField GuideBlogAbout
← pH7x KnowledgePowerShell

How to authenticate PnP.PowerShell with a ClientId

Why does Connect-PnPOnline demand a client id, and what do I register?

By João Livio·pH7x Knowledge

30-second answer

powershell
Register-PnPEntraIDAppForInteractiveLogin -ApplicationName "PnP Scripts" `
  -Tenant contoso.onmicrosoft.com
# The command above prints the app id it registered. Use it from here on:
$appId = 'the id printed by the registration'
Connect-PnPOnline -Url https://contoso.sharepoint.com -Interactive -ClientId $appId

Since PnP.PowerShell 2.99 there is no shipped multi-tenant application: -ClientId is mandatory on every connection, and the id must be an app registration in your tenant.

What this proves

That your scripts authenticate as an application your organisation registered, with scopes your organisation consented to, instead of a shared identity every PnP user on earth once used.

What it does not prove

  • That the connection has the rights your script needs. The client id gets you authenticated; what you can read is decided by the delegated scopes on the registration and the rights of the signed-in user.
  • That a wrong id fails clearly everywhere. It fails at connect time with AADSTS700016: Application with identifier '...' was not found in the directory, which at least names the problem.

PowerShell

powershell
# Browser available: interactive
Connect-PnPOnline -Url https://contoso.sharepoint.com -Interactive -ClientId $appId

# No browser on this host: device code
Connect-PnPOnline -Url https://contoso.sharepoint.com -DeviceLogin -ClientId $appId

Example output

text
WARNING: AADSTS700016: Application with identifier '31359c7f-...' was not
found in the directory 'e5373...'. 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.

Explanation

The example output is the failure you will actually meet: the id of the old shared PnP application, or of an app from another tenant, produces AADSTS700016 before anything reaches SharePoint. The fix is never to find "a working id" on a forum; it is to register an application in your own tenant and consent to the scopes your work needs. One registration serves all your scripts.

Production considerations

  • Choose the login flow before you connect. After a device-code login, PnP refuses to switch to the tenant administration context, so a script that needs Get-PnPTenantSite must authenticate against https://<tenant>-admin.sharepoint.com from the start.
  • Device login exists for hosts without a browser; it is not a way around consent.
  • Certificate-based application login (unattended, no user) is a separate registration with application permissions and admin consent.

References