Github Workflow Failing at Azure login

[Logeswari25]

While deploying the pipeline I am getting below error.

I'm not sure why I'm encountering this issue. Any help or guidance would be greatly appreciated.

Here is my work flow:

[YanaXu]

Hi @Logeswari25, please follow this example:

  - uses: azure/login@v2
    with:
      creds: '{"clientId":"${{ secrets.AZURE_CLIENT_ID }}","clientSecret":"${{ secrets.AZURE_CLIENT_SECRET }}","subscriptionId":"${{ secrets.AZURE_SUBSCRIPTION_ID }}","tenantId":"${{ secrets.AZURE_TENANT_ID }}"}'

And please consider using OIDC instead of SP+secret. Check here.

[k3-yasuda]

I also encountered the same error.

https://www.powershellgallery.com/packages/Az.Accounts/3.0.0
Recently, the version of Az.Account has been increased.
I think this is the effect.

[YanaXu]

Hi @k3-yasuda
could you please try below commands with the latest Az.Accounts to see if any errors are thrown?

$psLoginSecrets = ConvertTo-SecureString '<clientSecret>' -AsPlainText -Force
$psLoginCredential = New-Object System.Management.Automation.PSCredential('<clientId>', $psLoginSecrets) 
Connect-AzAccount -ServicePrincipal -Environment 'azurecloud' -Tenant '<clientId>' -Subscription '<subscriptionId>' -Credential $psLoginCredential 

[svenski]

We are encountering the same error across many GH action workflows trying to login to Azure (azure/login@v1). These builds were working yesterday.

Edit: To clarify, this a blocker across a few project currently.

Attempting Azure PowerShell login by using service principal with secret...
Error: Login failed with SyntaxError: Unexpected token R in JSON at position 0. Double check if the 'auth-type' is correct. Refer to https://github.com/Azure/login#readme for more information.

[kornel-lugosi-lab49]

With @ v2 we are seeing some more info:

Login failed with SyntaxError: Unexpected token 'R', "Retrieving"... is not valid JSON. Double check if the 'auth-type' is correct.

Maybe we are not following redirects?

[Abhijitk914]

We are also facing same issue Azure login with few gihub action step but some of the steps executed successfully. Please find below logs of both the execution (failed and sucessfull)

------------Failed Logs ---------------

Run azure/login@v2
Running Azure CLI Login.
/usr/bin/az cloud set -n azurecloud
Done setting cloud: "azurecloud"
Federated token details:
issuer - https://token.actions.githubusercontent.com
subject claim - repo:*******/-azure-bicep:environment:
Attempting Azure CLI login by using OIDC...
Subscription is set successfully.
Azure CLI login succeeds by using OIDC.
Running Azure PowerShell Login.

---

Result: '/home/runner/.local/share/powershell/Modules/Az.Accounts/3.0.0/Az.Accounts.psd1',
Success: true

---

Federated token details:
issuer - https://token.actions.githubusercontent.com
subject claim - repo:*******/-azure-bicep:environment:cu8
Attempting Azure PowerShell login by using OIDC...
Error: Login failed with SyntaxError: Unexpected token 'R', "Retrieving"... is not valid JSON. Double check if the 'auth-type' is correct. Refer to https://github.com/Azure/login#readme for more information.

------------ Successful Logs ---------------

Run azure/login@v2
Running Azure CLI Login.
/usr/bin/az cloud set -n azurecloud
Done setting cloud: "azurecloud"
Federated token details:
issuer - https://token.actions.githubusercontent.com
subject claim - repo:*********/-azure-bicep:environment:**
Attempting Azure CLI login by using OIDC...
Subscription is set successfully.
Azure CLI login succeeds by using OIDC.
Running Azure PowerShell Login.

---

Result: '/usr/share/az_11.3.1/Az.Accounts/2.19.0/Az.Accounts.psd1',
Success: true

---

Federated token details:
issuer - https://token.actions.githubusercontent.com
subject claim - repo:*******************/**-azure-bicep:environment:
Attempting Azure PowerShell login by using OIDC...
*** Success: true, Result: '' ***
Running Azure PowerShell Login successfully.

[sandeep5234]

Login failed with SyntaxError: Unexpected token 'R', "Retrieving"... is not valid JSON. Double check if the 'auth-type' is correct.

we are seeing same issue as above, Most of our critical workflows are failing. Is anyone working to resolve this ?

[ealasgarov]

Workaround:
The issue is caused by Az.Accounts PS module. We had latest (3.0.0) installed on our self-hosted github runners and this was causing a problem. I've realized the azure/login github action works fine on managed (ubuntu-latest) runners where Az.Account ver. 2.19.0 is installed. Downgrading the version solves the issue.

[joannewilsonRel]

I am using "ubuntu-latest" and have one workflow that is running into this issue. Any other ideas on how to address this?

[paulanguiano]

@YanaXu please relabel this issue, as it was incorrectly triaged.

We have many workflows affected by this bug in the login action.

Because of our supply chain controls I've been unable to test with a downgraded Az.Accounts module, but I'm working on it.

[mblaschke-daimlertruck]

Can confirm this issue with a high number of affected workflows.

Why is this issue still not fixed and why are Az PowerShell modules not tested before they are released?

[sentara-cshannah]

We are also seeing issues, and my self-hosted runners have not been updated to Az.Accounts yet. Still using 2.19.0 and I am getting this issue.

[sentara-cshannah]

Would this have something to do with the issue.

https://learn.microsoft.com/en-us/powershell/azure/release-notes-azureps?view=azps-11.6.0

Important

Preannouncement: The default interactive login experience will change from browser based to Web Account Manager (WAM) based on supported platforms, learn more. Only interactive login flow is influeced by WAM. This will take effect from the release of May 21st.

[mblaschke-daimlertruck]

@sentara-cshannah

But these are all non-interactive logins, so either azure/login is doing something wrong or Az.Accounts is broken.

it seems that azure/login is searching for the latest version of Az.Accounts, so make sure that you only have 2.19.0 installed.

[tim-chaffin]

Workaround: The issue is caused by Az.Accounts PS module. We had latest (3.0.0) installed on our self-hosted github runners and this was causing a problem. I've realized the azure/login github action works fine on managed (ubuntu-latest) runners where Az.Account ver. 2.19.0 is installed. Downgrading the version solves the issue.

@sentara-cshannah - Can you detail how you instruct your Runner to use a specific version of said dependency? Is that something you prescribe in the .yml somewhere?

[sentara-cshannah]

@mblaschke-daimlertruck , your right, my eyes glossed over the interactive part. I just confirmed that 3.0.0 is on my runner, though I wondering how it got installed since the image this runner is built on is a week or so old. Does the Azure/login action update that? And if so I am also and curious how we role back and stay rolled back.

[mblaschke-daimlertruck]

By installing an older version of Az module you will end up installing Az.Accounts 3.0.0 because the dependency is defined as Az.Accounts (>= 2.19.0)
see https://www.powershellgallery.com/packages/Az/11.6.0

Workaround after installing Az module:

Uninstall-Module -Name Az.Accounts
Install-Module -Name Az.Accounts -RequiredVersion 2.19.0

[sentara-cshannah]

yeah no good for me. I removed 3.0.0 and reran my job. 1st login worked fine, 2nd login failed same error. And it looks like it re-downloaded 3.0.0

[dcaro]

We'll be looking into this issue with high priority.

[mblaschke-daimlertruck]

@sentara-cshannah
I would recommend ephemeral runners, so throw them away after each job.

If you're running a Kubernetes cluster it's worth looking at https://github.com/actions/actions-runner-controller

[sentara-cshannah]

@mblaschke-daimlertruck thanks for the advice, I'd add it to my backlog. :)

[DanielTillmannTR]

Same issue, although I only see it in a workflow triggered by workflow_call.

[paulanguiano]

Okay, I can confirm that rolling back to Az.Accounts 2.x allows login to work again. However, anytime I load another Az module with a dependency on Az.Accounts, even if I specify a very old version of it, the version of Az.Accounts is bumped to 3.0.0 again. I've identified several scenarios now that bump the version of Az.Accounts silently and were preventing workarounds from working for us until now. I'm appalled by this kind of behavior, but thankfully I'm not responsible for powershell supply-chain attack security.

[YanaXu]

I have an instance where the downgrade to a previous release allows the login, but the next step has a dependency on Az.Accounts 3.0.0

Ultimately this makes it a blocker for other stations where there are other Microsoft owned actions that require the newer version of Az.Accounts

Note mostly to accommodate those of us that can't leverage the login work-around because we are contingent on other pieces of the workflow that need to have the upgraded dependency. In my situation, my subsequent action is the Enterprise Policy as Code action process to plan/deploy policy from a repository. I assume this won't be the only situation where this will be problematic, but it's my current block for testing new policies in the environments that I need to deploy to.

Hi @crypticraven, correct me if I'm wrong.

• Your workflow file depends on Az.Accounts 3.0.0 which means downgrade of Az.Accounts is not OK for your situation.
• Your workflow file has policy check which will disallow you to use the workaround azure/login@hf_447_release.

If yes to both the questions, the only workaround is login with Azure PowerShell directly instead of Azure Login Action.
You can check my example here for OIDC login with Azure PowerShell in GitHub Action.

[YanaXu]

immediate fix release

Hi @brendanlafond and @apalich , I'm planing the release but it will take some time. I'll update the status of the fix release in this issue and keep you all posted.

[wangrandk]

I have the same issue, i think i could solve it by using OIDC, but still gives the same issue. I aint know how to go on.

[crypticraven]

* Your workflow file depends on `Az.Accounts 3.0.0` which means downgrade of Az.Accounts is not OK for your situation.

No, there are other PowerShell modules that rely on Az.Accounts 3.0.0 that are used later in my action workflow. I tried downgrading to a version that didn't require Az.Accounts 3.0.0 and it allowed the login to be successful without an error. The Enterprise Policy-as-Code module relies on newer versions of the Az module as a whole.

* Your workflow file has policy check which will disallow you to use the workaround `azure/login@hf_447_release`.

I don't have a policy check process in my workflow. I don't want to limit use of this because it makes work-arounds harder to implement later. I was hoping to spread the message that downgrading may not be an option for everyone if there are other parts of the workflow process that need the updated components. This error currently prevents me from being able to manage Azure Policy (this is something I need to do every day). I acknowledge that I may be a minority here. I will be patiently waiting for the next release in hopes that it will resolve the issues presented today in the workflow.

[paulanguiano]

We are explicitly downgrading Az.Accounts to 2.19 before the azure/login action, and then installing/importing modules as needed after that, since any such action auto-updates Az.Accounts to 3.0.0. We haven't found a way to pin versions to prevent this behavior, which is a significant risk to our supply chain controls. Using a non-release version of the action in our production environment would take longer to get approval for, assuming our Risk dept allowed it through.

We're disturbed that the action was not tested against new api releases (is this a potential problem with every update of the pwsh modules?) and that we don't have adequate control over versioning (there's going to be a lot of discussion with our package management server team).

[camfarris]

@YanaXu @crypticraven
I've confirmed that the workaround for EPAC of explicitly getting the token and running connect-azaccount works. However, if you're using the something similar to the standard EPAC workflows from the starter kit, you will need to explicitly install az.accounts so it gets the correct version. Otherwise, it'll still throw the same error about needing 3.0.0, even though it clearly shows 3.0.0 is being installed.

It's annoying and doesn't make sense, but it works. It also doesn't make sense, because the code for the EPAC module specifically calls out needing v2.19.0... But whatever. It works.

[YanaXu]

Hi @Logeswari25, @k3-yasuda, @svenski, @kornel-lugosi-lab49, @Abhijitk914, @sandeep5234, @ealasgarov, @joannewilsonRel, @paulanguiano, @mblaschke-daimlertruck, @sentara-cshannah, @tim-chaffin , @DanielTillmannTR, @VillaDaniele, @haflidif, @wesco-prathapmotupalli, @crypticraven, @apalich, @brendanlafond, @wangrandk,

The fix is released in v2.1.1 and v2 is agligned with v2.1.1.
Please try

uses: azure/login@v2

or

uses: azure/login@v2.1.1

in your workflow file.

Feel free to create an issue in this repo if you met any problems. Thanks!

[YanaXu]

We are explicitly downgrading Az.Accounts to 2.19 before the azure/login action, and then installing/importing modules as needed after that, since any such action auto-updates Az.Accounts to 3.0.0. We haven't found a way to pin versions to prevent this behavior, which is a significant risk to our supply chain controls. Using a non-release version of the action in our production environment would take longer to get approval for, assuming our Risk dept allowed it through.

We're disturbed that the action was not tested against new api releases (is this a potential problem with every update of the pwsh modules?) and that we don't have adequate control over versioning (there's going to be a lot of discussion with our package management server team).

Hi @paulanguiano,
I fully understand your ask. It's caused by the current implementation mechanism. Whenever a new version of Az.Accounts is released, the GitHub Action runner will automatically use it. In rare cases, it will cause incompatibility issues with Azure Login Action. But this situation is indeed very rare, and both from the perspective of Azure Login Action and Azure PowerShell, we are trying to avoid this kind of thing. But in the unlikely event that it does happen, just like this issue, we will fix it as quickly as possible at all levels. No worries. In the future, we will also look at areas that can be improved in the entire workflow to improve the stability of everyone's workflow.

[YanaXu]

ing v2.19.0... But whatever

Hi @camfarris,

I think you're talking about another thing. Could you please open a new issue for this? We'd like to keep one issue for one topic. Thanks.

[VillaDaniele]

Hi,
I have tested a workflow both with v2 and v2.1.1 (in different runs) and it worked as intended with both versions.

[FreddyAyala]

Whenever a new version of Az.Accounts is released, the GitHub Action runner will automatically use it. In rare cases, it will cause incompatibility issues with Azure Login Action. But this situation is indeed very rare, and both from the perspective of Azure Login Action and Azure PowerShell, we are trying to avoid this kind of thing. But in the unlikely event that it does happen, just like this issue, we will fix it as quickly as possible at all levels. No worries. In the future, we will also look at areas that can be improved in the entire workflow to improve the stability of everyone's workflow.

I was using v1 and everything suddenly stopped working. I had to hunt down this GitHub post to figure out what went wrong and how to fix it by updating the azure/login part in our setup. This was a surprise for folks who've been using the same setup for a long time without any issues. The thing is, if I choose to upgrade to the new version and it doesn't work, I should be able to just go back to the old version and have it work like before. But this time, nothing was changed and still, everything broke. I get that you guys can fix things fast when there's a problem, but we really need to make sure old setups don't get messed up when new things come out. Could we do something about that? Thanks.

[YanaXu]

Whenever a new version of Az.Accounts is released, the GitHub Action runner will automatically use it. In rare cases, it will cause incompatibility issues with Azure Login Action. But this situation is indeed very rare, and both from the perspective of Azure Login Action and Azure PowerShell, we are trying to avoid this kind of thing. But in the unlikely event that it does happen, just like this issue, we will fix it as quickly as possible at all levels. No worries. In the future, we will also look at areas that can be improved in the entire workflow to improve the stability of everyone's workflow.

I was using v1 and everything suddenly stopped working. I had to hunt down this GitHub post to figure out what went wrong and how to fix it by updating the azure/login part in our setup. This was a surprise for folks who've been using the same setup for a long time without any issues. The thing is, if I choose to upgrade to the new version and it doesn't work, I should be able to just go back to the old version and have it work like before. But this time, nothing was changed and still, everything broke. I get that you guys can fix things fast when there's a problem, but we really need to make sure old setups don't get messed up when new things come out. Could we do something about that? Thanks.

Hi @FreddyAyala , sorry for your bad experience. Most of the time, the issues are introduced by Login Action itself and downgrade/upgrade of the action version works. But in rare cases, the action itself does not change but it may have compatibility issues with the platform it works with. In this case, downgrade/upgrade of the action version will not work. We are aware of this kind of problems and are continuously working on improving it. Feel free to open issues whenever you find an error or want to provide suggestions. Thanks.

[larsmaes-sogeti]

It seems there still is a problem. We are encountering this error with 2.1.1

Error: Login failed with SyntaxError: Expected double-quoted property name in JSON at position 240. Double check if the 'auth-type' is correct. Refer to https://github.com/Azure/login#readme for more information.

[neilmca-inc]

Just started using GitHub Actions today - and followed this example exactly including the workflow

https://learn.microsoft.com/en-us/azure/developer/github/connect-from-azure-secret

Received the same error as @larsmaes-sogeti

[error]Login failed with SyntaxError: Expected double-quoted property name in JSON at position 240. Double check if the 'auth-type' is correct. Refer to https://github.com/Azure/login#readme for more information

Not a great start is it! And it's August now - what is the fix?

Using azure/login@v2.1.1 does not work either

[YanaXu]

Just started using GitHub Actions today - and followed this example exactly including the workflow

https://learn.microsoft.com/en-us/azure/developer/github/connect-from-azure-secret

Received the same error as @larsmaes-sogeti

[error]Login failed with SyntaxError: Expected double-quoted property name in JSON at position 240. Double check if the 'auth-type' is correct. Refer to https://github.com/Azure/login#readme for more information

Not a great start is it! And it's August now - what is the fix?

Using azure/login@v2.1.1 does not work either

Hi @larsmaes-sogeti & @neilmca-inc , it's a closed issue with fix. We may miss your comments on a closed issue. Please open a new issue for your cases. Provide your secrets.AZURE_CREDENTIALS value (mask the json property values) in the new issue. I think you may put a wrong json value in the GitHub secrets. Please provide your GitHub runner information too. If it's self-hosted, please provide the Azure PowerShell version and Az.Accounts version. Thanks.

[neilmca-inc]

Thanks @YanaXu

I've fixed this now @larsmaes-sogeti - the official documentation contains invalid JSON ! There is a comma at the end of the last line

[YanaXu]

Thanks @neilmca-inc ! We'll see if we can update it.