Support AAD authentication for Azure DevOps feed.

[henriblMSFT]

PowerShellGet V2 only supports PAT token authentication, while this is a good start the experience contrast heavily with almost all other tools using azure devops. git doesn't require the use of PAT, neither does nuget restore.

[SydneyhSmith]

Thanks @henriblMSFT this is definitely an issue we want to look closer at and resolve as a top priority post-GA of 3.0, we have started the discussion in issue #330 so I will link the issues and mark this as duplicate. Thanks!

[LukasAltinell]

I just want to add to this topic that feature is a must have for being able to move over our organization to use Azure DevOps artifacts/feed. We are writing tools for different departments, and it's hard enough for them to get to the point where they use our repositories.

[StevenBucher98]

@LukasAltinell @henriblMSFT What do you envision the current flow to be? Automatic based on the current user or interactive?

Right now, we are working on integrating Secrete Management with PowerShellGet to help integrate credentials quicker and easier. Are you looking to have a more typical AAD scenario?

cc: @PaulHigin

[LukasAltinell]

@StevenBucher98 Currently we use a couple of SMB-shares for our Powershell Repositories and manage access through ACL's on those shares. It's enough trouble to guide our fellow first-line, client and infrastructure (primarily) people to register the repositories and to start consuming our modules and scripts (tools built for them), as well as keeping them updated locally. They are currently on a quite low level and every extra step is quite the hassle for them. For them to also logon to Azure Devops (which also requires a license) and request a PAT (with the correct permissions) before they can continue to register/install/update modules and scripts would simply not work (not to mention update the PAT when it expires).

My hope is that we can interactively pop up a dialog for them to enter their AAD-credentials (with conditional access policies) and get access that way. If that means that we under-the-hood request a PAT and keeping that up to date, that would be fine.

In this case we'll be trying to utilize the "Members of your Azure Active Directory" (Any members of your AAD can view the packages in this feed), and the use case above is primarily based on that flow (ie. consume, not produce).

[ghost]

This issue has been marked as duplicate and has not had any activity for 1 day. It will be closed for housekeeping purposes.