Implementing Authentication

[PalmEmanuel]

More and more new features that were building require authentication. We have plans on adding a dependency on the lightweight module AzAuth for getting a token for the user, but we can present this functionality in different ways resulting in different workflows.

Currently we use the authentication of Azure CLI or the Az PowerShell module. We don't need to remove it as an option in case the user wants to use that workflow, but here are some alternatives.

1 - Always providing a token

When the user does not want to use, or does not have access to Az CLI or the Az module, they can provide the token with a Token parameter for the appropriate commands. This token is not saved, and running another command will need the token to be provided again.

The simplest option. Leaving the Token parameter out would make the module look for tokens from the Az CLI or the Az module instead.

2 - Saving the token in the module

If we want to make it more convenient for the user, we need to store the credential somehow.

2.1 Connect-Bicep

One alternative matching a normal PowerShell workflow is to use a Connect- command before being able to use other commands. We could implement Connect-Bicep and store the token in our module scope, and add checks to see if the user is authenticated or not.

I think the workflow is reasonable, but it does not feel very intuitive to connect to the module since its main use is Bicep file management / conversion.

2.1.1 Session-bound Tokens

Managing the token comes with a couple of options, the most obvious one is to force the user to use the Connect-Bicep command each new PowerShell session. We could store the token either in PSBicep in PowerShell, or in BicepNet as a static credential (same result for the user).

Not as convenient as using the Az module or CLI in conjunction with our module, since the persist the credential between sessions.

2.1.2 Custom Persistent Token Cache

The more advanced, but probably doable option, is to create functionality in AzAuth to be able to specify our persistent own cache to serialize and store our token in, which we can then find a token from upon loading the module, if one exists.

2.2 Automatic token caching

Another alternative but without the Connect- command is to add a Token parameter to the commands, and cache it on use. If the user afterwards does not add a Token parameter, we use the one provided.

This feels like a worse option. It's not clear where the token would come from, and it would make it tricky to also allow the user to use Az CLI and the Az module.

[PalmEmanuel]

These thoughts are from discussions with @nilsson-jens yesterday, which prompted me to explore some options for authentication using AzAuth. I'm leaning towards having our own persistent credential cache if possible, but I'm not sure how I feel about a Connect- command.