powerplatform-vscode icon indicating copy to clipboard operation
powerplatform-vscode copied to clipboard

pac command work initially but starts failing with auth issues after ~ 1 hours

Open martintoelk opened this issue 2 years ago • 2 comments

Hi all,

pac works like a charm, but after ~ 1 hour, pac commands start to fail in our pipeline. 1 hour seems suspicious, it feels like pac cli is having issues refreshing the access token.

following auth command is used pac auth create --name "{name}" --url "{envUrl}" --applicationId "{appId}" --clientSecret "{Secret}" --tenant {tenant}

Example:

`pac solution import --path 'D:\solution_managed.zip' --convert-to-managed --activate-plugins --force-overwrite --import-as-holding --publish-changes --async --max-async-wait-time 120 Connected to...Microsoft PowerPlatform CLI Version: 1.18.4+g1a00e63

Error: Failed to connect to Dataverse Failed to connect to Dataverse One or more errors occurred. ExternalTokenManagement Authentication Requested but not configured correctly. 003 A configuration issue is preventing authentication - check the error message from the server for details. You can modify the configuration in the application registration portal. See https://aka.ms/msal-net-invalid-client for details. Original exception: AADSTS7000215: Invalid client secret provided. Ensure the secret being sent in the request is the client secret value, not the client secret ID, for a secret added to app '***'.`

martintoelk avatar Sep 27 '22 12:09 martintoelk

@martintoelk this is a known issue with no easy fix: for non-interactive OAuth flows using appId/clientSecrets, MSAL requires use of its ConfidentialClient object model. In MSAL, that OM no longer makes a refreshToken available, so to refresh an expiring/expired access token requires access to the secret again. The way how pac CLI works, this is split into 2 different pac CLI incantation, one for auth, one for import; the latter has no access anymore to the secret.

We've faced that same problem for our CI/CD tasks/actions, but for threat model reasons, we do not want the pac CLI to persist user secrets by default. The current opt-in model that is implemented in pac CLI and e.g. PP-BT tasks:

  • call pac auth create with the appId/secret/tenant triple as usual
  • create an env variable named: PAC_CLI_SPN_SECRET and store the client secret in it
  • call pac solution import ... with the usual params
  • once the accessToken is close to expiration or has expired, the pac CLI's internal refresh logic looks for that env variable and re-request a new accessToken via MSAL
  • remove the env variable once the solution import has finished

On Windows, we could use DPAPI to more securely store that client secret, but that API is not available in macOS nor linux. There's a MSAL extension available, but it depends on having e.g. a linux GUI with a keyring manager installed and available, But the main use case for appID is non-interactive, w/o GUI, think: linux build agents/runners, so that extension isn't helpful

AB#2937663

davidjenni avatar Sep 27 '22 15:09 davidjenni

@davidjenni thank you for your fast reply on this issue. Unfortunately we can't get this workaround by setting the PAC_CLI_SPN_SECRET to work.

How do we set the PAC_CLI_SPN_SECRET correctly in an azure hosted build agent on azure pipelines. We don't know the secret by start of the pipeline, we just fetch it from a key vault by an az cli task in the pipeline, then authenticate.

beef9r avatar Oct 14 '22 07:10 beef9r