azuread / microsoft-authentication-cli Goto Github PK

AzureAuth 0.7.2 can't create the mutex on Mac because of the mutex path contains a / which is not allowed on Unix.

Currently, in our README, we have release and download badges containing the latest version number and number of downloads for that version respectively.

Once the release pipeline succeeds, we have to manually update their references to the latest version. These badges should be updated automatically to point to the released version.

Method names like AuthMode.IsBroker() and AuthMode.IsWeb() are slightly confusing. It's not necessarily the case that a given AuthMode enum is AuthMode.Broker so much as it's the case that AuthMode.Broker is enabled/supported.

Having --clear take over and do something entirely different on that command, and not actually be tied to the specific client/scope pair is confusing. This would likely be better suited in it's own reset command that attempts to reset all state related to AzureAuth for more holistic troubleshooting and debugging.

When trying to install the 1ES DevTool on MacOS and coreutils installed through Homebrew, I'm getting an error installing the azureauth cli that seems related to a bad parsing of uname -a in install.sh

Error obtaining access token: [System.Exception: Error installing azureauth cli. Log: . Error: Unsupported architecture 'Darwin', unable to download a release

Changing from uname -a | rev | cut -d ' ' -f1 | rev to grepping for x86_64 or arm64 seems to work - PR incoming

C# 8.0 brings a few things we could take advantage of

• Nullable types - better null checking at compile time
• async streams - AuthFlowExector could be an async stream of AuthFlowResults.

The warning in this section of code introduced in #153

could probably be more generic and refer to a non-Microsoft solution. How else could we phrase this?

PS C:\Users\seadams> $env:AZUREAUTH_VERSION = '0.6.0'
PS C:\Users\seadams> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
PS C:\Users\seadams> iex "& { $(irm https://raw.githubusercontent.com/AzureAD/microsoft-authentication-cli/${env:AZUREAUTH_VERSION}/install/install.ps1) } -Verbose"
VERBOSE: Installing using post-0.4.0 method
VERBOSE: Creating C:\Users\seadams\AppData\Local\Programs\AzureAuth
VERBOSE: Downloading
https://github.com/AzureAD/microsoft-authentication-cli/releases/download/0.6.0/azureauth-0.6.0-win10-x64.zip to
C:\Users\seadams\AppData\Local\Programs\AzureAuth\azureauth-0.6.0-win10-x64.zip
VERBOSE: Extracting C:\Users\seadams\AppData\Local\Programs\AzureAuth\azureauth-0.6.0-win10-x64.zip to
C:\Users\seadams\AppData\Local\Programs\AzureAuth\0.6.0
VERBOSE: Removing C:\Users\seadams\AppData\Local\Programs\AzureAuth\azureauth-0.6.0-win10-x64.zip
VERBOSE: Appending 'C:\Users\seadams\AppData\Local\Programs\AzureAuth\0.6.0' to $env:PATH

WARNING: The data being saved is truncated to 1024 characters.
Installed azureauth 0.6.0!

setx truncates the path to 1024 characters, opening a new shell "azureauth" isn't found on the path
. https://superuser.com/questions/387619/overcoming-the-1024-character-limit-with-setx

Post CachedAuth refactor, we can assert the log statements made in auth flows, and the auth flow base class.

seanadams@Seans-MacBook-Pro ~ % azureauth
The --resource field or the --scope field is required.
The --client field is required.
The --tenant field is required.
The option --cache=.IdentityService/msal_.cache or environment varable AZUREAUTH_CACHE=`` is not a valid absolute file path.

Fresh install of 0.6.0, opened new terminal and ran azureauth with no params and got the error.

To apply variable expansion, this line
$url = 'https://raw.githubusercontent.com/AzureAD/microsoft-authentication-cli/${env:AZUREAUTH_VERSION}/install/install.ps1'

needs to be changed to (double quotes)
$url = "https://raw.githubusercontent.com/AzureAD/microsoft-authentication-cli/${env:AZUREAUTH_VERSION}/install/install.ps1"

The installer creates a "latest" folder which corresponds to the most recent version of the auth tool. On windows, this folder is a complete copy rather than a link.

While making a symbolic link requires administrator permission, creating a directory junction (mklink /j latest v0.2.0) does not and can be used here to avoid having a second copy of the tool.

method is no longer used just for PATs.

The PowerShell install script (install/install.ps1) is currently unsigned, requiring anyone running it to bypass PowerShell's execution policy, potentially allowing a vector for a supply-chain attack (especially since it isn't obvious or easy to get a hash of the install scripts so that clients can verify them).

Can you please provide a signed version of the script - either checked-in or as part of the release artifacts.

(All version numbers are examples.) If you install v0.2.0 of the AuthTool and then subsequently install v0.1.0, the 'latest' folder will point at the v0.1.0 version and not the v0.2.0 version.

Using the latest folder is great for not having to update config files when a new version is released, but if that folder can "regress" to an easlier version, it's usefullness is more limited.

This could either be done with a flag to the install script or with a separate set of platform-specific uninstall scripts. Either way, though we'd be sad to see them go, users might appreciate this.

Environment Variables can be declared at the workflow, job, or step level.

The release.yml workflow makes use of the ${{ github.event.inputs.version }} in many places and this can be shortened a little by defining that as an env var on the whole workflow.

The ESRP signing scripts currently dont have the json files added to the releases programmatically.

We might be able to leverage async streams to clean up some of our code, especially with the Auth Flow Executor.

Tried to install and was getting a 404 error. Looks like https://github.com/AzureAD/microsoft-authentication-cli/releases/tag/0.8.4 is broken.

When we create encrypted storage properties right now we configure the object to know how to work with all platforms. This might not be necessary. We should investigate whether it makes sense to conditionally compile parts of that process. Here's an example of that usage currently.

We briefly looked at upgrading MSAL versions in #82, but couldn't justify upgrading at the moment.

We do still want to upgrade MSAL versions, but after we've identified a version that delivers sufficient benefit and has been deployed long enough to guarantee some measure of stability.

This is a tracking issue to make sure we don't drop that task.

I've noticed azureauth (version 0.5.4 and 0.6.0) is taking a 20-45 seconds to return anything. Subsequent runs are fast but this is happening for token calls as well as azureauth with no parameters and "azureauth -h". I recently updated to 11.7.1, not sure if that is related but didn't noticed any issues prior to updating to 11.7.1. Is there any logs or ways I can help debug this?

Right now the AuthMode enum is not aware of the various platforms at runtime. This pushes the logic of determining which auth modes are support onto a caller when the enum could just "know" what platforms are supported directly.

When AzureAuth devicecode mode is invoked, telemetry (only when explicitly enabled) doesn't populate the mode name correctly. Refer to the screenshot below:

We need to fix it as it would enable to us to query telemetry better.

On Windows Server 2012, with PowerShell 4.0, if the target directory exists, the installation script will delete all files in the folder finally.

Here I think we should build a prompt hint to pass in, so that is always has AzureAuth CLI at the beginning. Perhaps a helper method to construct our prompt hint, that we can call here.

Something like

private const string PromptHintPrefix = "Azure AUth CLI";
private string GetPromptHint() {
  if (string.IsNullOrEmpty(this.PromptHint) {
    return PromptHintPrefix;
  }
  else
  {
    return $"{PromptHintPrefix}: {this.PromptHint}";
  }
}

Originally posted by @kyle-rader in #11 (comment)

Right now we have 2 different secrets, that are used for 2 different ADO Orgs, but the names don't imply which is for which.
I think we can avoid future confusion by changing them to:

• ADO_PAT_MICROSOFT
• ADO_PAT_OFFICE

When we do azureauth --help, the help text displayed contains random blank lines for some of the CLI options. The help text should be consistent so that either all options appear after a blank line or none have blank lines.